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1.0 INTRODUCTION 


1.1 Identification of Document 

The Software Management and Assurance Program (SMAP) Information 
System Life-Cycle and Documentation Standards Document describes 
the Version 4 standard information system life-cycle in terms of 
processes, products, and reviews. The description of the 
products includes the detailed documentation standards. 


1.2 Scope of Document 

The standards in this document set can be applied to the life- 
cycle and documentation of all NASA information systems. An 
"information system" is a software- intensive system; it is any 
combination of software, hardware, and operational procedures 
required to process, store, or transmit data. This document 
includes standards for life-cycle and documentation for informa- 
tion systems and their software, hardware, and operational 
procedures components. 

This standard is limited to the specification of a life-cycle 
model and documentation content. It does not define specific 
management, engineering, or assurance standards. 

Use of the SMAP Information System Life-Cycle and Documentation 
Standards is determined on a program/project basis. Hence, the 
application, tool support, and enforcement of these standards is 
the responsibility of the program/project management. 


1.3 Purpose and Objectives of Document 

The purpose of this document is to define a standard life-cycle 
model and content for associated documentation. These standards 
provide a framework to allow consistency across the agency and 
also visibility into the completeness of the information 
recorded . 


1.4 Document Status and Schedule 

Release 4.2C was the first complete release for Version 4 of the 
Information System Life-Cycle and Documentation Standards 
document. All five volumes of the document underwent a SMAP and 
agency review. Release 4.3 is an update to Release 4.2C based on 
the approved RIDs from this review. The RID review board 
determined that change bars will not be used to show the 
differences between Releases 4.2C and 4.3, as 4.3 is the first 
baselined release of the Version 4 standards. 
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1.5 Document Organization and Roll-Out 

This document is organized into ten sections, as follows: 

o Section 1 defines the scope and purpose of the document 

o Section 2 lists applicable documents 

o Section 3 provides an overview and background of the 
information system life-cycle and documentation 
standards 

o Section 4 contains the standards. The Life-Cycle Standard 
describes the information system and component life-cycles 
in detail, including the rules for their use. The detailed 
documentation standards related to the life-cycle have been 
rolled-out into separate volumes: 

- Management Plan Documentation Standard and Data Item 
Descriptions 

- Product Specification Documentation Standard and Data 
Item Descriptions 

- Assurance Specification Documentation Standard and Data 
Item Descriptions 

- Management Control and Status Reports Documentation 
Standard and Data Item Descriptions 

o Section 5 discusses the application and support of the 

standards with emphasis on guidelines for use of the life- 
cycle. (Guidelines for use of the document standards are 
contained in the appropriate documentation standard volume.) 

o Section 6 contains suggestions on the assurance and en- 
forcement of the standards 

o Sections 7 and 8 define the abbreviations, acronyms, and 
significant terms used throughout the standards 

o Sections 9 and 10 are available for notes and appendices 
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2 . 0 RELATED DOCUMENTATION 


2 . 1 Parent Documents 


None. 


2.2 Applicable Documents 

The following volumes/documents are referenced herein and are 

directly applicable to this document: 

1) Management Plan Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

2) Product Specification Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

3) Assurance Specification Documentation Standard and Data Item 
Descriptions (DID) Volume of the Information System 
Life-Cycle and Documentation Standards, Release 4.3, 

2/28/89. Washington: NASA Office of Safety, Reliability , 

Maintainability, and Quality Assurance. 

4) Management Control and Status Reports Documentation Standard 

and Data Item Descriptions (DID) Volume of the Information 
System Life-Cycle and Documentation Standards, Release 4.3, 
2/28/89. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

5) IEEE Standard Glossary of Software Engineering Terminology. 

ANSI/IEEE Std 729-1983. New York: Institute of Electrical 

and Electronic Engineers, Inc. 


2 . 3 Information Documents 

The following documents, although not directly applicable, are 
referenced for historical continuity: 

1) Military Standard for Defense System Software Development, 
DoD-STD-2 167 , 4 June 1985, and DOD-STD-2167A, 27 October 1987. 

2) NASA Software Data Item Descriptions, Version 3, November 

1986. Washington: NASA Office of Safety, Reliability, 
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Maintainability, and Quality Assurance. (Additional Data 
Item Descriptions were published as Versions 3.1 - 3.5 in 
1987.) 

3) Space Station Program Software Management Policies, November 
1986. 

4) Chart. NASA Information System Life-Cycle Inter-relation- 
ships: A Phased-Del ivery Model. December 1987. Washington: 

NASA Office of Safety, Reliability, Maintainability, and 
Quality Assurance. 

5) Chart. NASA Software Acquisition Life-Cycle. Version 3.0, 

10/15/86. Washington: NASA Office of Safety, Reliability, 

Maintainability, and Quality Assurance. 

6) Information Processing Resources Management, NHB 2410. ID, 
April 1985. 

7) Management of Federal Information Resources, OMB Circular 
No. A-130, 12 December 1985. 

8) System Safety Engineering Methodologies, NHB 1700. 1(V7), 
March 1988 . 

9) Assuring the Security and Integrity of NASA Automated 
Information Resources, NMI 2410. 7A, Draft Rev. 3/14/88. 
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3.0 OVERVIEW OF THE LIFE-CYCLE AND DOCUMENTATION STANDARDS 


3.1 Scope of the Life-Cycle and Documentation Standards 

A life-cycle is a series of steps, called phases, used to 
coordinate and control the development and sustaining engineering 
of an information system or hardware, software, or operational 
procedures component. Each phase consists of a set of activities 
to accomplish the goals of the phase and of associated products 
of those activities. A review, called a phase transition review, 
is defined as a mechanism for determining when to transition from 
one phase to the next. 

The SMAP Information System Life-Cycle and Documentation 
Standards are applicable to all NASA information systems and 
hardware, software, and operational procedures components. 

The selection, adaptation, and enforcement of these SMAP 
standards is the responsibility of the cognizant program/pro j ect 
manager. 

It is important to note that these life-cycle and documentation 
standards are not management, technical and engineering, or 
assurance standards. However, the life-cycle is defined in terms 
of management, engineering, and assurance activities to be 
conducted in each phase. The documentation standards provide the 
organization for recording the results of these management, 
engineering, and assurance activities. 


3.2 Rationale for the Life-Cycle and Documentation Standards 

The rationale for the life-cycle definition and documentation 
structures presented in this standard is to provide: 

1) A model for organizing and executing management, engineer- 
ing, and assurance activities. This model supports sound 
management, engineering, and assurance practices, and NASA 
standards regarding these activities. 

2) A method of organizing information about life-cycle acti- 
vities such that users, authors, and reviewers of documenta- 
tion know where to find or place each item of information. 

3) Uniformity of format and content of documentation throughout 
NASA programs/pro j ects for ease of use and understanding. 

4) A reference document which can be used as a checklist 
during document reviews. 

These standards were derived from Version 3 of the SMAP Data Item 
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Descriptions (DIDs) based on industry feedback to: 1) provide 

relationships between different pieces of information (DIDs) ; 

2) supply a tailoring mechanism for the DIDs; and 3) present a 
system perspective. The SMAP life-cycle and documentation 
standards are based upon the assumption that it is the 
responsibility of program/project management to: 

1) Select, adapt, and enforce the life-cycle model for the 
program/ project and for each information system and major 
component within the program/project. 

2) Select what information is to be formally recorded, adapt 
the documentation standards for each information system and 
component of the program/project, and enforce the use of the 
specified adaptation. 


3.3 Interface with Other Standards 

At the time of the publication of Release 4.3 of the SMAP 
Information System Life— Cycle and Documentation Standards, there 
are no other SMAP information system standards. However, these 
life-cycle and documentation standards have been designed to be 
supportive of a broad range of potential management, technical 
and engineering, and assurance standards including existing 
detailed standards such as NASA and NASA Center technical 
hardware standards. 


3.4 Definition of Major Concepts and Terms 

Prior to presenting the life-cycle and documentation standards, 
it is essential to define basic terminology and concepts included 
in these standards. 

The acquirer is the organization obtaining (acquiring]) an 
information system or component. Providers are organizations 
performing a function or providing a capability to the acquirer. 

An information system is composed of hardware, software, and 
operational procedures components required to process, store, 
and/or transmit data. See Figure 3-1. Within the context of 
this standard, an information system is a software-intensive 
system. 
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The operational procedures are the manual procedures or processes 
(conducted by the operator of the system) that are an integral 
part of an information system's operational capability provided 
to the users. During system design, decisions related to 
automated versus manual processes, and hardware versus software 
(i.e., allocation of requirements to the various components) are 
made. 

Within this definition, then, an "operator" (i.e., someone 
executing the operational procedures) is internal to the 
information system and a user is external to the information 
system. That is, the user utilizes the capabilities of the 
information system in performing a task. "Operators," executing 
the operational procedures, work in conjunction with the hardware 
and software to provide the operational capabilities of an 
information system to the users. 

The life-cycle and documentation standards are supportive of 
system decomposition concepts. During design of an information 
system, the system may be decomposed into another level of 
information systems (referred to as subsystems) or into software, 
hardware, and operational procedures components. During the 
design of a component, it may be decomposed into another level of 
like components (or subcomponents) , or it may proceed into 
detailed design and implementation. 

An example of an information system decomposition tree depicting 
several levels of decomposition is presented in Figure 3-2 . 

A separate life-cycle is instantiated for each node in an 
information system's decomposition tree. The result is parallel 
life-cycles as depicted in Figure 3-3. The life-cycles of a node 
and its subordinate nodes inter- relate in terms of schedules, 
milestones, and products to be delivered from the subordinate 
nodes for review and approval. Further discussion and guidelines 
concerning decomposition and life-cycle adaptations are presented 
in Section 5 of this document. 

When reading or applying these life-cycle and documentation 
standards, it is important to recognize that the position of the 
node in the information system decomposition tree affects the 
relationships, decisions, and application of these standards. 
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Figure 3-3. Information System Tree Life-Cycle. 
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4.0 THE LIFE-CYCLE AND DOCUMENTATION STANDARDS 


4.1 Life-Cycle and Documentation Introduction 

Each information system and component life— cycle consists of the 
following phases : 

o Concept and Initiation: Includes evaluating the feasibility 

of the proposed information system or component, developing 
the management strategy and constraints, and defining the 
information system or component concept 

o Requirements: Includes defining the development process and 

assurance strategies , and determining the technical require- 
ments for an information system or component 

o Design: Includes designing an information system or compo- 

nent and allocating the requirements to design elements 

o Implementation £ Coordination] : Includes coordinating and 

monitoring the implementation of the (next lower level) 
subsystems or components, or the actual implementation of a 
component 

o Integration and Test: Includes integrating the (next lower 

level) subsystems or components or the component units, and 
integration testing 

o Acceptance and Delivery: Includes validating that the 

delivered information system or component meets the techni- 
cal and user's requirements 

o Sustaining Engineering and Operations: Includes sustaining 

the operational capabilities of the information system or 
component, including repairs and upgrades within the context 
of the original concept of the system or component 

The basic life-cycle model for an information system is depicted 
in Figure 4-1. The component life-cycles are defined in terms of 
variations from the information system life— cycle as illustrated 
in Figure 4-2. 
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Figure 4-1. Information System Life-Cycle 
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Figure 4-2. Component Life-Cycle Phase Variations. 
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Section 4.2 presents in detail the information system life-cycle 
model and Section 4.3 presents the software life-cycle model. 
Sections 4.4 and 4.5 present the hardware and operational 
procedures life— cycle models as variations from the information 
system model. Each model is presented by life-cycle phase. The 
phase is described in terms of its activities, products, and the 
phase transition review. 

The activities for each phase are defined in terms of management, 
engineering, and assurance activities: 

a) Management activities include all planning activities and 
the tracking and modification of the plans based on status, 
metric, and other feedback reports. 

b) Engineering activities include the actual concept defini- 
tion, requirements analysis, design, and implementation 
activities. 

c) Assurance includes quality assurance, testing, quality 
engineering assurance, safety assurance, security and 
privacy assurance, verification and validation, and 
certification of both the products and processes. 

Assurance activities include the definition of specifica- 
tions, procedures, criteria, and test and other evaluation 
expectations; the actual conduct of an assurance function 
such as a test or review; and the analysis of the results. 

The documentation products for each life— cycle instantiation 
consist of a four-document set (see Section 4.6 for more 
details) . The documentation set includes: 

o A management plan 

o A product specification 

o An assurance specification 

o A management control and status reports document 

All planning activities are documented in the appropriate 
sections of the management plan. All engineering activities are 
documented in the appropriate sections of the product 
specification. All assurance (technical) activities are 
documented in the appropriate sections of the assurance 
specification. 

The management control and status reports document is intended to 
provide a logical home for all reports. In general, these are 
management (status and performance) , engineering (change 
request) , and assurance (review) reports submitted to management 
as feedback on plans, processes, schedules, etc. 

All documentation products of the life-cycle phases are specified 
in terms of content for a section of one of these four documents. 
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Specific details concerning the format, content, and organization 
of documentation is presented in Section 4.6. 

A phase transition review is a major assurance activity that is 
conducted at the end of a phase to assure the products of that 
phase and to determine the readiness to proceed to the next 
phase. Further discussion of these reviews is presented in 
Section 4.7. 

The life-cycles presented are models. It is assumed that they 
will be adapted for a specific information system or component by 
the cognizant management. Guidelines for common adaptations such 
as incremental development, phased delivery, and evolutionary 
acquisition, are presented in Section 5.1. (See the Glossary for 
definition of these terms.) 

In addition, the life-cycle model does not assign responsibili- 
ties. The life-cycle model defines basic activities which are to 
be conducted and products to be generated or updated within a 
particular life-cycle phase. It is the responsibility of the 
information system or component management to assign specific 
responsibility for activities and document such assignment in the 
management plan. 

The actual rules governing the use of this standard are presented 
in Section 4.8. 
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4.2 Information System Life-Cycle Definition 

The information system life-cycle consists of the following 
phases : 

o Information System Concept and Initiation 
o Information System Requirements 
o Information System Design 

o Information System Implementation Coordination 
o Information System Integration and Test 
o Information System Acceptance and Delivery 
o Information System Sustaining Engineering and Operations 

This life-cycle is instantiated for each information system in 
the system decomposition tree. 


4.2.1 INFORMATION SYSTEM CONCEPT AND INITIATION PHASE 

The objectives of the Information System Concept and Initiation 
Phase are to evaluate the feasibility of the proposed information 
system, compile the user requirements, define the information 
system concept and scope, define the assurance strategy, and 
develop the management strategy and constraints for development 
of the information system. 


4. 2. 1.1 Management Activities 

Management planning begins in this phase by defining both the 
activities and structure of the organization obtaining the system 
(called the acquirer) , and the development and assurance process 
requirements. Development process requirements definition 
includes procurement strategy decisions, life-cycle requirements 
and constraints, engineering standards and constraints, delivery 
requirements, and tracking and control mechanisms. Assurance 
process requirements definition includes criticality 
classification of the information system, specification of the 
types of assurance activities to be performed, and assurance 
standards . 

Included as part of the acquirer's management planning is how the 
acquirer intends to track progress, quality, and other project 
attributes. This requires the specification of the metric 
information, to be collected and evaluated within the acquirer's 
organization, which will be supplied by either the acquirer or 
the providers (such as the developer). The acquirer's 
configuration management plan and assurance plan is also defined 
at this time. 

If the acquirer intends to formally procure the development of 
the information system, then the procurement activities and 
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requirements are defined at this time. If the assurance plan 
includes procurement of independent verification and validation, 
then planning and definition of this procurement are also 
conducted. Results of this entire planning process are 
documented in the Acquisition Planning section of the Information 
System Management Plan. 

In this phase and all subsequent phases of the life-cycle, 
lessons learned reports of the management control and status 
reports are completed and delivered, at a minimum, to the NASA 
Code Q Software Management and Assurance Program (SMAP) . These 
reports should be completed at periodic intervals, but are 
provided at least at the end of every life-cycle phase. Each 
report includes an evaluation of the use of these Information 
System Life-Cycle and Documentation Standards. 


4.2. 1.2 Engineering Activities 

System feasibility studies are performed and the system concept 
is developed. The system operational concept including 
operational scenarios are determined. Results are documented in 
the Concept section of the Information System Product 
Specification. 


4 . 2 . 1 . 3 Assurance Activities 

Assurance activities of this phase include the specification of 
and actual conduct of reviews of the Acquisition Plan and the 
Concept. The review specifications and results are documented in 
the appropriate Quality Assurance sections of the Assurance 
Specification. Reports describing the outcome of these reviews 
are documented in the Management Control and Status Reports 
document. 


4 . 2 . 1 . 4 Product Summary 

Management Plan: Acquisition Plan 

Product Specification: Concept 

Assurance Specification: Quality Assurance - Review 

Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
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4 . 2 . 1 . 5 Phase Transition 

The Information System Initiation and Concept Phase concludes 
with the successful completion of the review of the Concept 
section of the Product Specification and Acquisition Planning 
section of the Management Plan. 

At this and all subsequent phase transition reviews, all products 
developed or modified within that phase are reviewed and placed 
under configuration management. 
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4.2.2 INFORMATION SYSTEM REQUIREMENTS PHASE 

The objectives of the Information System Requirements Phase are 
to formally procure the development and/or independent 
verification and validation (if required) of the information 
system, define the development processes, perform requirements 
analysis, and establish risk and management control mechanisms. 


4.2.2. 1 Management Activities 

If the development of the information system is to be formally 
procured, then the procurement activities defined in the previous 
phase are implemented by the acquirer. These include preparation 
of the statement of work (SOW) and request for proposal (RFP) 
package, source evaluation and selection, and contract 
negotiation. If independent verification and validation (IV&V) 
is to be procured, then these procurements activities are 
implemented by the acquirer. 

After procurement, or at the beginning of this phase if no formal 
procurements are necessary, the planning for development is 
conducted by the development provider. This Development Plan 
conforms to the process requirements and constraints specified in 
the Acquisition Plan. The Development Plan includes the 
identification of the approach and definition of the methods for 
all activities (management, engineering, and assurance) performed 
by the development provider. At a minimum these include: 

o work breakdown structure, resource allocation, and 
schedules; 

o risks and contingencies identification and planning 
assessment ; 

o engineering, integration, and operational transition 

methods and approach, including use of prototyping, phased 
delivery, and incremental development in the engineering 
and intergration process; 

o configuration management process and procedures to 
support the engineering approach; 

o assurance activities and approach, and quality evaluation 
approach and metrics; 

o detailed requirements for each phase-ending audit and 
review ; 

o identification of products to be baselined at or before 
the end of each phase; 
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o development personnel training planning; and 

o resource, quality, and other tracking information, 
including specific metric data to be collected during 
the development process. 

If incremental development adaptation is utilized, the definition 
of the specific increments along with the prioritization approach 
to be used in selecting which parts of the information system 
will be developed first is documented within the Development 
Planning section of the Management Plan. 

If new procedures and standards are required, they are developed 
and documented in the standards repository. (Note that it may be 
appropriate to generate a development plan and product 
specification to document the development process of new 
standards or other support products.) 

The approaches and mechanisms defined during this planning 
process are documented in the Development Plan section of the 
Information System Management Plan. They are used in subsequent 
phases for the development, tracking, and control of the 
information system by the development provider. 

If independent verification and validation is specified in the 
Management Plan, then the approach and methods are defined and 
documented in the Verification and Validation Planning subsection 
of the Assurance Plan section of the acquirer's Acquisition 
Planning section of the Management Plan. 

The acquirer, or designated provider, develops the sustaining 
engineering and operations approach for support of the 
information system after delivery. This includes planning for 
maintenance, repair, upgrades, spares, logistics training, and 
other aspects appropriate to the specific information system. 

This information is documented in the Sustaining Engineering and 
Operations Planning section in the Information System Management 
Plan. If evolutionary acquisition is specified or anticipated, 
the acquirer or designee prepares the Evolutionary Acquisition 
Planning section of the Management Plan. 

Management participates in the product reviews, and/or evaluates 
the review and status reports, to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the design activities of the next phase are 
initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 
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4. 2. 2. 2 Engineering Activities 

The engineering activities of this phase include the definition 
of the technical requirements with traceability to the design of 
the next higher level information system in the system 
decomposition tree (if any). The activities performed to support 
the requirements definition may include: 

a) User needs investigation. 

b) User scenarios development. These scenarios detail 
the user interface retirements to the system but do 
not detail the specific man-machine interface. 

c) Prototyping, as required and defined in the engineering 
and integration approach in the Development Plan section of 
the Management Plan. 

d) External interface definition and evaluation. 

e) Requirements synthesis and analysis. 

f) Partitioning of the requirements for phased delivery, if 
required. 

The results are documented in the Requirements section of the 
Information System Product Specification. In addition, a 
preliminary version of the User's Guide section of the 
Information System Product Specification is developed. 

If phased deliveries are identified in the information system 
engineering and integration approach defined in the Development 
Planning _ section of the Management Plan, then the partitioning of 
the requirements into specific deliverables is performed and 
documented in the Requirements section. 

If the development of the information system is being formally 
procured, the acquirer may develop the requirements as part of 
the SOW/RFP package. 

Metric information (as specified in the Development Planning 
section of the Management Plan) is collected for the tracking and 
evaluation of the information system and documented in the 
Management Control and Status Reports document. 
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4 . 2 . 2 . 3 Assurance Activities 

The acceptance test process is initiated in this phase through 
the development of the Acceptance Test Specifications, in 
conformance with the Assurance Plan's approach (detailed in the 
Management Plan), and supports any phased delivery requirements. 
Acceptance tests are based on requirements and ^ user scenarios. 

The acceptance test information is documented in the appropriate 
testing section(s) of the Assurance Specification. 

If verification and validation or independent verification and 
validation has been specified in the Management Plan, then the 
validation specifications are defined. The specifications, 
criteria, procedures, measurement, and expected results for 
verification activities for (at least) this phase are 
developed. Verification activities for this phase are conducted 
and results documented. All (independent) verification and 
validation assurance information is documented in the appropriate 
Verification and Validation section of the Assurance 
Specification. Any verification reports generated are documented 
in the Management Control and Status Reports document. 

The specifications, procedures, criteria, etc. for other quality, 
safety, and security assurance activities, as specified in the 
Management Plan to be conducted in this phase, are also 
generated . 

Other assurance activities include reviews of the Management Plan 
sections developed in this phase, of the Requirements section of 
the Product Specification, and of sections of the Assurance 
Specification developed in this phase. If any changes were made 
to previously reviewed products, these are also reviewed. All 
review information is documented in the Assurance Specification. 
The outcome of these reviews is documented in review reports in 
the Management Control and Status Reports document. All 
deficiencies and discrepancies are documented in discrepancy 
reports in the Management Control and Status Reports document and 
responsibility for resolution assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in performance and/or metric reports in the 
Management Control and Status Reports document . 
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4 . 2 . 2 . 4 Product Summary 

Management Plan: 

Procurement Package 
Development Plan 

Sustaining Engineering and Operations Plan 
Evolutionary Acquisition Plan 
Independent Verification and Validation Plan 
Product Specification: 

Requirements Specification 
User's Guide (preliminary) 

Assurance Specification: 

Acceptance Test Specifications 

Quality Assurance Specifications, Procedures, 

Criteria, and Results 

Quality Engineering Assurance Specifications, 

Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria, and Results 

Security and Privacy Assurance Specifications, 

Procedures, Criteria, and Results 
(Independent) Verification Specifications, Procedures, 
Criteria, and Results 
(Independent) Validation Specifications 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 

At any phase, updates may occur to the products of the previous 
phases . 


4.2.2. 5 Phase Transition 

The Information System Requirements Phase concludes with the 
successful completion of the Requirements Review for the 
information system. 
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4.2.3 INFORMATION SYSTEM DESIGN PHASE 

The objective of the Information System Design Phase is to 
perform architectural design and allocation of the information 
system requirements to its architectural design elements (either 
subsystems or components) . 


4.2.3. 1 Management Activities 

The collected metric information is evaluated to determine the 
status of the information system. This information is used for 
tracking and, when necessary, modifying the resource estimation 
and other project attributes. Identified risk areas are 
re-evaluated per the risk assessment process defined in the 
Information System Management Plan. As a result of the above, 
planning modifications and updates are made, as required, and 
documented in the appropriate planning sections of the Management 
Plan and also in Management and Control Status Reports document. 

If the information system design is composed of subsystems, then, 
as this system enters the subsequent phase (implementation 
coordination) , the lower-level systems each begin a new instance 
of the information system life-cycle. Incremental development or 
phased delivery development decisions of this system may impose 
phased delivery requirements on these information subsystems. 

If the information system design is composed of components 
(hardware, software, and operational procedures) then, as this 
system enters the subsequent phase (implementation coordination) , 
each component begins execution of its life-cycle. Incremental 
development or phased delivery development decisions of this 
information system may impose phased delivery requirements on the 
components . 

If the entire information system is to be acquired off-the-shelf, 
then procurement and selection preparation is conducted in this 
phase . 

Management participates in the product reviews and/or evaluates 
the review and status reports to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the implementation activities of the next 
phase are initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 
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4. 2. 3. 2 Engineering Activities 

Engineering design ? requirements allocation, and design 
partitioning into increments (if required) are conducted in 
conformance with the methods and approach designated in the 
engineering and integration approach of the Development Planning 
section of the Management Plan. Traceability to the requirements 
is developed and documented. 

If the entire information system is intended to be acquired 
off-the-shelf, then the identification, evaluation, and selection 
process is initiated in this phase. 

During design, the information system's architecture is defined 
either in terms of subsystems (lower-level information systems) 
or components (software, hardware, and operational procedures) . 
The interfaces between the design elements (subsystems or 
components) are defined during this phase. The requirements of 
this information system are then allocated to the design elements 
(subsystems or components) . 

If an incremental development approach is being employed, then 
the increments are detailed at this time. The increments 
(partitions of design) defined must be consistent with any phased 
delivery partitioning defined in the requirements. 

Results of all these design activities, along with the design 
rationale, is documented in the Design section of the Information 
System Product Specification. (The design rationale and 
trade-off analysis information is vital to information system 
maintenance personnel to understand why certain design decisions 
were made . ) 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 


4. 2. 3. 3 Assurance Activities 

The acceptance test process continues with the development of the 
acceptance test procedures and criteria. These are documented in 
the appropriate Acceptance Test section of the Assurance 
Speci f icat ion . 

If verification and validation and/or independent verification 
and validation has been specified in the Management Plan, then 
verification of the design is conducted and findings documented 
in the Assurance Specification. Also, validation procedures and 
criteria are developed. Any reports are documented as Management 
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Control and Status Reports document verification or review 
reports . 

The integration test process is initiated in the phase through 
development of the Integration Test Specification. This 
specification conforms to the assurance approach defined in the 
Development Plan and supports any incremental development 
reguirements . Integration tests (based on the design 
information) are documented in the Integration Test section of 
the Information System Assurance Specification. 

Other assurance activities include reviews of all management, 
engineering, and assurance products developed in this phase plus 
any changes to previously reviewed products. All review 
activities are documented in review reports. Deficiencies and 
discrepancies are documented in discrepancy reports, and 
responsibility for resolution assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 


4 . 2 . 3 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: Design Specification 

Assurance Specification: 

Acceptance Test Procedures and Criteria 

Integration Test Specifications, Procedures, and Criteria 
Quality Assurance Specifications, Procedures, 

Criteria, and Results 

Quality Engineering Assurance Specifications, 

Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria, and Results 

Security and Privacy Assurance Specifications, 

Procedures, Criteria, and Results 
(Independent) Verification Specifications, Procedures, 
Criteria , and Results 

(Independent) Validation Procedures and Criteria 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 
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4. 2. 3. 5 Phase Transition 

The Information System Design Phase concludes with the successful 
completion of the Design Review for the information system. This 
review is conducted to evaluate the optimization, traceability, 
correlation, completeness, and the risk of the design, including 
the corresponding test specifications. 
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4.2.4 INFORMATION SYSTEM IMPLEMENTATION COORDINATION PHASE 

The objective of the Information System Implementation 
Coordination Phase is to review the products of this information 
system's design elements (i.e. f subsystems or components) and 
coordinate the interaction among and implementation decisions of 
them during their development. If the entire system is acquired 
off-the-shelf, this phase is used to complete procurement of the 
system and prepare for acceptance testing. 


4. 2. 4.1 Management Activities 

The collected metric information is evaluated to determine the 
status of the information system. This information is used for 
tracking and, when necessary, modifying the resource estimation 
and other project attributes. Identified risk areas are 
r e-evaluated per the risk assessment process defined in the 
Information System Management Plan. As a result of the above, 
modifications and updates to plans are made, as required, and 
documented in appropriate Management Plans and Management Control 
and Status Reports documents. 

If the system design was defined in terms of subsystems 
(lower-level systems) or components during the design phase, 
then, as their life-cycles are executed, evaluation and 
coordination is conducted throughout their life-cycles. 

If the entire information system is acquired off-the-shelf, then 
management support of the procurement and selection process is 
conducted during this phase. 

Management participates in the product reviews and/or evaluates 
the review and status reports to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the testing activities of the next phase 
are initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4 . 2 . 4 . 2 Engineering Activities 

Implementation activities are conducted in conformance with the 
methods and approach designated in the Development Plan section 
of the Management Plan. 

If the information system architecture is defined in terms of 
subsystems (lower-level systems) or components, then review and 
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coordination of the lower-level technical activities is 
supported. This includes review and coordination of the 
interface specifications between the subsystems or components and 
of their requirements and designs. 

If the entire information system is acquired off-the-shelf, then 
final selection and procurement is conducted in this phase. If 
the entire information system is acquired as one delivery, then 
integration testing is not required. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 


4. 2. 4. 3 Assurance Activities 

The remaining preparation for integration test activities, 
including test procedures, criteria, and test case development, 
is completed at this time and documented in the Integration Test 
section of the Information System Assurance Specification. 
Incremental development requirements must be supported. 

Final preparation for acceptance testing is completed at this 
time, including test case development. Phased delivery 
requirements must be supported. 

In addition to the review of the integration and acceptance test 
products developed in this phase, assurance activities include 
the review of all the (next lower-level) subsystems or components 
products if this system has been so defined. All review 
activities are documented in review reports and, if necessary, 
discrepancy reports. 

If verification and validation and/or independent verification 
and validation of this information system is specified in the 
Management Plan for subsystems or components, then some amount of 
verification of the (lower-level) subsystems or components 
products may be conducted and findings documented in the 
Assurance Specification. In addition, preparation for conducting 
validation of this information system is completed by the end of 
this phase. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 
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4 . 2 . 4 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: Updates, as required 

Assurance Specification: 

Integration Test Procedures, Criteria, and Cases 
Acceptance Test Cases 

Quality Assurance Specifications, Procedures, 

Criteria, and Results 

Quality Engineering Assurance Specifications, 

Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria, and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria, and Results 
(Independent) Verification Specifications, Procedures, 
Criteria , and Results 

(Independent) Validation Test Cases and Expected Results 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4 . 2 . 4 . 5 Phase Transition 

The Information System Implementation Coordination Phase 
concludes as (lower-level) subsystems or components become ready 
for systems integration and test (i.e., complete their Acceptance 
and Delivery Phase) . There is usually no formal transition 
review. If the entire information system is acquired 
off-the-shelf, then the phase concludes once that system has been 
procured . 
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4.2.5 INFORMATION SYSTEM INTEGRATION AND TEST PHASE 

The objective of the Information System Integration and Test is 
to integrate the (next lower-level) subsystems or components and 
to perform integration testing. 


4. 2. 5.1 Management Activities 

The collected metric information is evaluated to determine the 
status of the information system. This information is used for 
tracking and, when necessary, modifying the resource estimation 
and other project attributes. Identified risk areas are 
re-evaluated per the risk assessment process defined in the 
Information System Management Plan. As a result of the above, 
modifications and updates to plans are made, as required, and 
documented in appropriate Management Plans and Management Control 
and Status Reports document. 

Management participates in the product reviews, and/or evaluates 
the review and status reports, to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the acceptance test activities of the next 
phase are initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4. 2. 5. 2 Engineering Activities 

Integration activities are conducted in conformance with the 
methods and approach designated in the Development Plan section 
of the Management Plan. The (next lower-level) subsystems or 
components which have passed their acceptance testing are 
integrated . 

Integration can be performed incrementally if specified in the 
Engineering and Integration section of the Development Plan and 
supported by the definition of the increments in the design 
document. Each increment undergoes integration testing assurance 
activities prior to integration with subsequent increments. 
Component (or subsystem) providers may be required to support 
system integration. 

If the entire information system was acquired off-the-shelf as 
one delivery, then integration may not be required. 

At the completion of integration, the Version Description 
Document section of the Product Specification is prepared. 
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Final versions of the user's guide and training materials for 
users and operators are developed during this phase along with 
the information system maintenance manual and documented in the 
appropriate sections of the Information System Product 
Specification. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 


4. 2. 5. 3 Assurance Activities 

At the completion of integration (for each increment if 
incremental development is used) , integration testing is 
conducted. Integration testing is often conducted by the 
engineering development team but may be performed by whatever 
organization is assigned responsibility per the Development 
Planning Section of the Management Plan. The results of all 
integration testing are documented in the appropriate test 
results section of the Assurance Specification. Any reports are 
documented in the Management Control and Status Reports 
document . 

At the completion of integration testing, the tests and their 
results are reviewed for assurance that the information system is 
ready for acceptance testing. The review results are documented 
in the Assurance Specification. Deficiencies and discrepancies 
are documented in discrepancy reports in the Management Control 
and Status Reports document and responsibility for resolution 
assigned . 

If verification and validation and/or independent verification 
and validation has been specified in the Management Plan, then 
verification of the product against the Design sections of the 
Product Specification is conducted and findings documented in the 
appropriate section of the Assurance Specification. If 
preparation for validation was not complete, it is finished and 
documented in the appropriate section of the Assurance 
Specification. Any reports are documented in the Management 
Control and Status Reports document. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 
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4 . 2 . 5 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: 

Information System (post-integration test) 

Version Description Document 
User's Guide 
Training Materials 
Maintenance Manual 
Assurance Specification: 

Integration Test Results 

Quality Assurance Specifications, Procedures, 

Criteria , and Results 

Quality Engineering Assurance Specifications, 
Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria , and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria, and Results 
(Independent) Verification Specifications, Procedures, 
Criteria , and Results 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4. 2. 5. 5 Phase Transition 

The Information System Integration and Test Phase concludes with 
the successful completion of the Test Readiness Review (TRR) of 
the information system. The Test Readiness Review is conducted 
to determine whether system acceptance test preparation is 
complete and to assure that the information system is ready for 
formal acceptance testing. A successful Test Readiness Review is 
usually predicated on the acquirer's determination that the 
acceptance test procedures and previous testing results form a 
satisfactory basis for proceeding into the Acceptance Testing 
Phase . 
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4.2.6 INFORMATION SYSTEM ACCEPTANCE AND DELIVERY PHASE 

The objectives of the Information System Acceptance and Delivery 
Phase are to validate that the information system meets its 
documented requirements and the users' needs and to prepare the 
information system for delivery. 


4.2.6. 1 Management Activities 

The collected metric information is evaluated to determine the 
status of the information system. This information is used for 
tracking and, when necessary, modifying the resource estimation 
and other project attributes. Identified risk areas are 
re-evaluated per the risk assessment process defined in the 
Information System Management Plan. As a result of the above, 
modifications and updates to plans are made, as required, and 
documented in appropriate Management Plans and Management Control 
and Status Reports document. 

Management participates in the product reviews, and/or evaluates 
the review and status reports, to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before final delivery of the information system 
and initiation of the sustaining engineering activities. 

The final accept or reject decision of the information system is 
the responsibility of management. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4. 2. 6. 2 Engineering Activities 

The engineering activities include preparation of the information 
system for delivery and performing operational transition 
activities, such as training and generation of a 
version-compatible release of the User's Guide and Version 
Description sections of the Product Specification. 

Metric information (as specified in the Development Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 
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4. 2. 6. 3 Assurance Activities 

Acceptance test activities are conducted in conformance with the 
methods and approach designated in the Assurance Plan section of 
the Management Plan. The activities in this phase include formal 
testing of the information system against the requirements and 
the user scenarios. 

If phased delivery is specified, then the acceptance testing is 
conducted on the system defined for the current delivery against 
the requirements defined for that delivery. The results from 
acceptance testing are documented in the Assurance 
Specification . 

If verification and validation and/or independent verification 
and validation is specified in the Management Plan, then the 
appropriate verification activities and all validation testing 
are conducted. Results are documented in the appropriate 
sections of the Assurance Specification. Reports are documented 
in the Management Control and Status Reports document. 

Acceptance test results and reports, along with any (independent) 
validation results and reports, are analyzed. An acceptance 
review is conducted and documented in a review report. 
Deficiencies and discrepancies are documented in discrepancy 
reports in the Management Control and Status Reports document, 
and responsibility for resolution is assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document . 


4 . 2 . 6 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: 

Information System (post-acceptance test) 

Version Description (update) 

User's Guide and Training Materials (update) 
Assurance Specification: 

Acceptance Test Results 

Quality Assurance Specifications, Procedures, 
Criteria, and Results 

Quality Engineering Assurance Specifications, 
Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 
Criteria , and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria, and Results 
(Independent) Verification and Validation Results 
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Management Control and Status Reports: 
Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Chancre Proposals 
Performance/Metrics Reports 


4. 2. 6. 5 Phase Transition 

The Information System Acceptance and Delivery Phase concludes 
with the successful completion of the Functional Configuration 
Audit (FCA) and the Physical Configuration Audit (PCA) , resulting 
in an accept or reject decision. The object of the Functional 
Configuration Audit and the Physical Configuration Audit is to 
validate that the actual performance of the information system as 
determined through test complies with the requirements 
specifications, and to identify the test report (s) and data which 
document results of acceptance tests. 


36 


Release 4.3, 2/28/89 



INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION STANDARDS 
INFORMATION SYSTEM: SUSTAINING ENGINEERING AND OPERATIONS PHASE 


4.2.7 INFORMATION SYSTEM SUSTAINING ENGINEERING AND OPERATIONS 
PHASE 

The objectives of the Information System Sustaining Engineering 
and Operations Phase are to sustain the operational capabilities 
of the information system, to make "repairs" and upgrades within 
the context of the original concept of the system, and to conduct 
user and operations training and support. 

Upgrades, either outside the scope of the original concept or 
involving the major rework of the implementation, may be 
considered outside of the scope of sustaining engineering 
activities and, thus, should be addressed in the evolutionary 
acquisition of the information system. Sustaining engineering, 
as defined here, includes maintenance. 


4 . 2 . 7 . 1 Management Activities 

Review and approval of discrepancy reports and change proposals 
is conducted by management. Modifications and updates to plans 
are made and documented in appropriate Management Plans and 
Management Control and Status Reports documents. Plans for 
change incorporation must adhere to the same acquisition and 
assurance requirements as originally identified for the 
information system classification level. 

Management participates in the product reviews, and/or evaluates 
the review and status reports, to determine the readiness to 
deliver the next release of the information system. Management 
is responsible for ensuring that all activities of this phase are 
conducted and documented. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4 . 2 . 7 . 2 Engineering Activities 

Technical evaluation of discrepancy reports and change proposals 
is performed. Changes to the information system are only 
implemented based on approved change reguests. This reguires 
iteration through the requirements, design, implementation, and 
testing phases of the life-cycle. The activities defined in 
those phases are performed, resulting in updates to the specified 
products . 

In addition to supporting the operations of the information 
system, user and operator training may be required as an on-going 
services . 
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Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 


4. 2. 7. 3 Assurance Activities 

To maintain the integrity and quality of the information system, 
the same types and levels of assurance must be conducted during 
sustaining engineering as were performed during development 
(previous phases of the life-cycle) . Reviews of all updated 
products are conducted and documented in review reports. 
Acceptance testing, verification and validation, and independent 
verification and validation activities are performed, as 
specified in the Management Plan. Regression testing is 
performed to assure that operational integrity is maintained. 
Test results are documented in the Assurance Specification. 

If required by system changes, modification to assurance 
specifications, criteria, test cases, and expected results are 
made. This will require updates to the Assurance Specification. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 


4 . 2 . 7 . 4 Product Summary 

Management Plan: Updates 

Product Specification: Updates 

Assurance Specification: Updates 

Management Control and Status Reports: 
Discrepancy Reports 
Engineering Change Proposals 
Status Reports 
Review Reports 
Performance/Metrics Reports 


4.2.7. 5 Phase Transition 

The Information System Sustaining Engineering and Operations 
Phase concludes with the retirement of the system or the 
transition to its next evolutionary phase. Reviews conducted 
during the Sustaining Engineering and Operations Phase are 
dependent upon the types of changes required. Sustaining 
Engineering requires re-visiting life-cycle phases. For each 
life-cycle phase revisited, the appropriate phase transition 
reviews are conducted. 
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4.3 Software Life-Cycle Definition 

The software life-cycle consists of the following phases: 

o Software Concept and Initiation 
o Software Requirements 
o Software Design 

- Architectural Design 

- Detailed Design 

o Software Implementation 
o Software Integration and Test 
o Software Acceptance and Delivery 

o Software Sustaining Engineering and Operations (Support) 

This life-cycle is instantiated for each software component (and 
software subcomponents) in the decomposition tree. 


4.3.1 SOFTWARE CONCEPT AND INITIATION PHASE 

The objectives of the Software Concept and Initiation Phase are 
to evaluate the feasibility of the proposed software concept (if 
not addressed during the feasibility evaluation of the 
information system) , define the software concept, and develop the 
management, engineering, and assurance strategies and 
constraints . 

Some of the activities for this phase may not be required due to 
their previous execution at higher levels in the system decompo- 
sition. For example, the software concept may have been fully 
defined at the information system level and the management 
planning may simply reference sections in the information system 
management plan. 


4. 3. 1.1 Management Activities 

Management planning begins in this phase by defining both the 
activities and structure of the organization obtaining the 
software (called the acquirer) , and the development and assurance 
process requirements. Development process requirements 
definition includes procurement strategy decisions, life-cycle 
requirements and constraints, engineering standards and 
constraints, delivery requirements, and tracking and control 
mechanisms. Assurance process requirements definition includes 
criticality classification of the software, specification of the 
types of assurance activities to be performed, and assurance 
standards . 

Included as part of the acquirer's management planning is how the 
acquirer intends to track progress, quality, and other project 
attributes. This requires the specification of the metric 
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information, to be collected and evaluated within the acquirer's 
organization, which will be supplied by either the acquirer or 
the providers (such as the developer). The acquirer's 
configuration management plan and assurance plan is also defined 
at this time. 

If the acquirer intends to formally procure the development of 
the software, then the procurement activities and requirements 
are defined at this time. If the assurance plan includes 
procurement of independent verification and validation, then 
planning and definition of this procurement are also conducted. 
Results of this entire planning process are documented in the 
Acquisition Planning section of the Software Management Plan. 

In this phase and all subsequent phases of the life-cycle, 
lessons learned reports of the management control and status 
reports are completed and delivered, at a minimum, to the NASA 
Code Q Software Management and Assurance Program (SMAP) . These 
reports should be completed at periodic intervals, but are 
provided at least at the end of every life-cycle phase. Each 
report includes an evaluation of the use of the software aspects 
of these Information System Life-Cycle and Documentation 
Standards . 


4 . 3 . 1 . 2 Engineering Activities 

Software feasibility studies are performed and the software 
concept is developed. The software operational concept including 
operational scenarios are determined during this phase. Results 
are documented in the Concept section of the Software Product 
Specification. 


4. 3. 1.3 Assurance Activities 

Assurance activities of this phase include the specification of 
and actual conduct of reviews of the Acquisition Plan and the 
Concept. The review specifications and results are documented in 
the appropriate Quality Assurance sections of the Assurance 
Specification. Reports describing the outcome of these reviews 
are documented in the Management Control and Status Reports 
document . 
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4 . 3 . 1 . 4 Product Summary 

Management Plan: Acquisition Plan 

Product Specification: Concept 

Assurance Specification: Quality Assurance - Review 

Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 


4. 3. 1.5 Phase Transition 

The Software Initiation and Concept Phase concludes with the 
successful completion of the review of the Concept section of the 
Product Specification and Acquisition Planning section of the 
Management Plan. 

At this and all subsequent phase transition reviews, all products 
developed or modified within that phase are reviewed and placed 
under configuration management. 
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4.3.2 SOFTWARE REQUIREMENTS PHASE 

The objectives of the Software Requirements Phase are to formally 
procure the development and/or independent verification and 
validation (if required) of the software, define the development 
process, perform requirements analysis, and establish risk and 
management control mechanisms. 


4. 3. 2.1 Management Activities 

If the development of the software is to be formally procured, 
then the procurement activities defined in the previous 
phase are implemented by the acquirer. These include preparation 
of the statement of work (SOW) and request for proposal (RFP) 
package, source evaluation and selection, and contract 
negotiation. If independent verification and validation (IV&V) 
is to be procured, then these procurements activities are 
implemented by the acquirer. 

After procurement, or at the beginning of this phase if no formal 
procurements are necessary, the planning for development is 
conducted by the development provider. This Development Plan 
conforms to the process requirements and constraints specified in 
the Acquisition Plan. The Development Plan includes the 
identification of the approach and definition of the methods for 
all activities (management, engineering, and assurance) performed 
by the development provider. At a minimum these include: 

o work breakdown structure, resource allocation, and 
schedules; 

o risks and contingencies identification and planning 
assessment ; 

o engineering, integration, and operational transition 

methods and approach, including use of prototyping, phased 
delivery, and incremental development in the engineering 
and intergration process; 

o configuration management process and procedures to 
support the engineering approach; 

o assurance activities and approach, and quality evaluation 
approach and metrics; 

o detailed requirements for each phase-ending audit and 
review; 

o identification of products to be baselined at or before 
the end of each phase; 
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o development personnel training planning; and 

o resource, quality, and other tracking information, 
including specific metric data to be collected during 
the development process. 

If incremental development adaptation is utilized, the definition 
of the specific increments along with the prioritization approach 
to be used in selecting which parts of the software will be 
developed first is documented within the Development Planning 
section of the Management Plan. 

If new procedures and standards are required, they are developed 
and documented in the standards repository. (Note that it may be 
appropriate to generate a development plan and product 
specification to document the development process of new 
standards or other support products . ) 

The approaches and mechanisms defined during this planning 
process are documented in the Development Plan section of the 
Software Management Plan. They are used in subsequent phases for 
the development, tracking, and control of the software by the 
development provider. 

If independent verification and validation is specified in the 
Management Plan, then the approach and methods are defined and 
documented in the Verification and Validation Planning subsection 
of the Assurance Plan section of the acquirer's Acquisition 
Planning section of the Management Plan. 

The acquirer, or designated provider, develops the sustaining 
engineering and operations approach for support of the software 
after delivery. This includes planning for maintenance, 
upgrades, training, and other aspects appropriate to the 
software. Sustaining Engineering may be specified for software, 
or it may be specified as an information system activity 
supported, as necessary, by software. This information is 
documented in the Sustaining Engineering and Operations Planning 
section in the Software Management Plan. 

Evolutionary acquisition is usually specified only at the 
information system level. If evolutionary acquisition is 
specified or anticipated for the software, the acquirer or 
designee prepares the Evolutionary Acquisition Planning section 
of the Management Plan. 

Management participates in the product reviews, and/or evaluates 
the review and status reports, to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the design activities of the next phase are 
initiated . 
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If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4. 3. 2. 2 Engineering Activities 

The engineering activities of this phase include the definition 
of the technical requirements with traceability to the design of 
the next higher level design in the system decomposition tree, 
either information system or software component. The activities 
performed to support the requirements definition may include: 

a) User needs investigation. 

b) User scenarios development. These scenarios detail 
the user interface requirements to the software but do 
not detail the specific man-machine interface. 

c) Prototyping, as required and defined in the engineering 
and integration approach in the Development Plan section of 
the Management Plan. 

d) External interface definition and evaluation. 

e) Requirements synthesis and analysis. 

f) Partitioning of the requirements for phased delivery, if 
required. 

The results are documented in the Requirements section of the 
Software Product Specification. In addition, a preliminary 
version of the User's Guide section of the Software Product 
Specification is developed. 

If phased deliveries are identified in the software engineering 
and integration approach defined in the Development Planning 
section of the Management Plan, then the partitioning of the 
requirements into specific deliverables is performed and 
documented in the Requirements section. 

If the development of the software is being formally procured, 
the acquirer may develop the requirements as part of the SOW/RFP 
package . 

Metric information (as specified in the Development Planning 
section of the Management Plan) is collected for the tracking and 
evaluation of the software and documented in the Management 
Control and Status Reports document. 
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4 . 3 . 2 . 3 Assurance Activities 

The acceptance test process is initiated in this phase through 
the development of the Acceptance Test Specifications, in 
conformance with the Assurance Plan's approach (detailed in the 
Management Plan) , and supports any phased delivery requirements. 
Acceptance tests are based on requirements and user scenarios. 

The acceptance test information is documented in the appropriate 
testing section (s) of the Assurance Specification. 

If verification and validation or independent verification and 
validation has been specified in the Management Plan, then the 
validation specifications are defined. The specifications, 
criteria, procedures, measurement, and expected results for 
verification activities for (at least) this phase are 
developed. Verification activities for this phase are conducted 
and results documented. All {independent) verification and 
validation assurance information is documented in the appropriate 
Verification and Validation section of the Assurance 
Specification. Any verification reports generated are documented 
in the Management Control and Status Reports document. 

The specifications, procedures, criteria, etc. for other quality, 
safety, and security assurance activities, as specified in the 
Management Plan to be conducted in this phase, are also 
generated . 

Other assurance activities include reviews of the Management Plan 
sections developed in this phase, of the Requirements section of 
the Product Specification, and of sections of the Assurance 
Specification developed in this phase. If any chanqes were made 
to previously reviewed products, these are also reviewed. All 
review information is documented in the Assurance Specification. 
The outcome of these reviews is documented in review reports in 
the Management Control and Status Reports document. All 
deficiencies and discrepancies are documented in discrepancy 
reports in the Management Control and Status Reports document and 
responsibility for resolution assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in performance and/or metric reports in the Management 
Control and Status Reports document. 
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4 . 3 . 2 . 4 Product Summary 

Management Plan: 

Procurement Package 
Development Plan 

Sustaining Engineering and Operations Plan 
Evolutionary Acquisition Plan 
Independent Verification and Validation Plan 
Product Specification: 

Requirements Specification 
User's Guide (preliminary) 

Assurance Specification: 

Acceptance Test Specifications 

Quality Assurance Specifications, Procedures, 

Criteria, and Results 

Quality Engineering Assurance Specifications, 

Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria , and Results 

Security and Privacy Assurance Specifications, 

Procedures, Criteria, and Results 
(Independent) Verification Specifications, Procedures, 
Criteria , and Results 
(Independent) Validation Specifications 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 

At any phase, updates may occur to the products of the previous 
phases . 


4 . 3 . 2 . 5 Phase Transition 

The Software Requirements Phase concludes with the successful 
completion of the Requirements Review for the software. 
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4.3.3 SOFTWARE DESIGN PHASE 

The Software Design Phase may be partitioned into two parts, with 
a phase transition review at the conclusion of each part if this 
software component is not further partitioned into software 
subcomponents. The two parts are architectural design and 
detailed design. 


4. 3. 3.1 SOFTWARE ARCHITECTURAL DESIGN 

The objective of the Software Architectural Design Phase is to 
perform architectural design and allocation of the software 
component's requirements to its architectural design elements or 
software subcomponents. 


4 . 3 . 3 . 1 . 1 Management Activities 

The collected metric information is evaluated to determine the 
status of the software. This information is used for tracking 
and, when necessary, modifying the resource estimation and other 
project attributes. Identified risk areas are re-evaluated per 
the risk assessment process defined in the Software Management 
Plan. As a result of the above, planning modifications and 
updates are made, as required, and documented in the appropriate 
planning sections of the Management Plan and also in the 
Management and Control Status Reports document. In addition, any 
reuse or commonality, and buy, build, or modify, plans for the 
software should be detailed at this time. 

If the software design is composed of software subcomponents , 
then the lower level software components each begin a new 
instance of the software life-cycle and this software component 
enters an implementation coordination phase analogous to the 
information system phase of this name. Incremental development 
or phased delivery development decisions of this software may 
impose phased delivery requirements on these software 
subcomponents . 

If the software is not further decomposed into software 
subcomponents, then the architectural design into design elements 
is conducted. This software component then proceeds to the 
detailed design phase. 

If the entire software component is to be acquired off-the-shelf, 
then procurement and selection preparation is conducted in this 
phase . 

Management participates in the product reviews and/or evaluates 
the review and status reports to determine the readiness to 
proceed to the next phase. Management is responsible for 
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ensuring that all activities of this phase have been conducted 
and documented before the implementation activities of the next 
phase are initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4. 3. 3. 1.2 Engineering Activities 

Engineering design, requirements allocation, and design 
partitioning into increments (if required) are conducted in 
conformance with the methods and approach designated in the 
engineering and integration approach of the Development Planning 
section of the Management Plan. Traceability to the requirements 
is developed and documented. 

If the entire software component is intended to be acquired 
off-the-shelf, then the identification, evaluation, and selection 
process is initiated in this phase. 

During design, the software's architecture is defined either in 
terms of software subcomponents (lower-level software components) 
or design elements. The interfaces between the design elements 
or subcomponents are defined during this phase. The requirements 
of this software are then allocated to the design elements or 
subcomponents . 

If an incremental development approach is being employed, then 
the increments are detailed at this time. The increments 
(partitions of design) defined must be consistent with any phased 
delivery partitioning defined in the requirements. 

Results of all these design activities, along with the design 
rationale, is documented in the Architectural Design section of 
the Software Product Specification. (The design rationale and 
trade-off analysis information is vital to software maintenance 
personnel to understand why certain design decisions were made.) 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 
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4 . 3 . 3 . 1 . 3 Assurance Activities 

The acceptance test process continues with the development of the 
acceptance test procedures and criteria. These are documented in 
the appropriate Acceptance Test section of the Software Assurance 
Spec i flea t ion . 

If verification and validation and/or independent verification 
and validation has been specified in the Management Plan, then 
verification of the architectural design is conducted and 
findings documented in the Assurance Specification. Also, 
validation procedures and criteria are developed. Any 
verification or review reports are documented in the Management 
Control and Status Reports document. 

The integration test process is initiated in the phase through 
development of the Integration Test Specification. This 
specification conforms to the assurance approach defined in the 
Development Plan and supports any incremental development 
requirements. Integration tests (based on the design 
information) are documented in the Integration Test section of 
the Software Assurance Specification. 

Other assurance activities include reviews of all management, 
engineering, and assurance products developed in this phase plus 
any changes to previously reviewed products. All review 
activities are documented in review reports. Deficiencies and 
discrepancies are documented in discrepancy reports, and 
responsibility for resolution assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 


4 . 3 . 3 . 1 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: Design Specification — Architectural 

Assurance Specification: 

Acceptance Test Procedures and Criteria 

Integration Test Specifications, Procedures, and Criteria 
Quality Assurance Specifications, Procedures, 

Criteria , and Results 

Quality Engineering Assurance Specifications, 

Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria , and Results 

Security and Privacy Assurance Specifications, 

Procedures, Criteria, and Results 
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(Independent) Verification Specifications, Procedures, 
Criteria , and Results 

(Independent) Validation Procedures and Criteria 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4 . 3 . 3 . 1 . 5 Phase Transition 

The Software Architectural Design Phase concludes with the 
successful completion of the Architectural (or Preliminary) 
Design Review for the software. This review is conducted to 
evaluate the optimization, traceability, correlation, 
completeness, and the risk of the design, including the 
corresponding test specifications. 
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4. 3. 3. 2 SOFTWARE DETAILED DESIGN PHASE 

The objectives of the Software Detailed Design Phase are to 
complete design to the unit level and prepare for software 
implementation. The activities in this phase are conducted only 
for the lowest software components in the decomposition tree and 
are dependent upon buy, build, or modify decisions. 


4. 3. 3. 2.1 Management Activities 

The collected metric information is evaluated to determine the 
status of the software. This information is used for tracking 
and, when necessary, modifying the resource estimation and other 
project attributes. Identified risk areas are re-evaluated per 
the risk assessment process defined in the Software Management 
Plan. As a result of the above, planning modifications and 
updates are made, as required, and documented in the appropriate 
planning sections of the Management Plan and also in the 
Management and Control Status Reports document. 

If the entire software component is to be acquired off-the-shelf, 
then procurement and selection preparation is conducted in this 
phase . 

Management participates in the product reviews and/or evaluates 
the review and status reports to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the implementation activities of the next 
phase are initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4. 3. 3. 2. 2 Engineering Activities 

Detailed design activities are conducted in conformance with the 
methods and approach designated in the Development Plan section 
of the Software Management Plan. 

Software detailed design includes design of the software design 
elements and software units. Buy, build, or modify decisions are 
made in this phase, and any necessary procurement activities 
conducted. The results of all detailed design activities are 
documented in the Detailed Design section of the Software Product 
Specification. 

If verification and validation and/or independent verification 
and validation has been specified in the Management Plan, then 
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verification of the detailed design is conducted and findings 
documented in the Assurance Specification. Any reports are 
documented as Management Control and Status Reports document 
verification or review reports. 

If the entire software component is acquired off-the-shelf as a 
single package, then detailed design activities, unit test 
development, and integration testing may be omitted. (The 
implementation phase would consist of final procurement 
activities and preparation for acceptance testing.) 

Metric information (as specified in the Development Plan) is 
collected for the tracking and evaluation of the software 
component and documented In the Management Control and Status 
Reports document. 


4. 3. 3. 2. 3 Assurance Activities 

If the software component is acquired off-the-shelf as a single 
package, then the software acceptance test cases are prepared in 
this phase. 

If the software is being developed, then software unit test 
specifications, procedures, and criteria are generated in this 
phase and documented in the Unit Test section of the Assurance 
Specification. 

Other assurance activities include reviews of all management, 
engineering, and assurance products developed in this phase plus 
any changes to previously reviewed products. All review 
activities are documented in review reports. Deficiencies and 
discrepancies are documented in discrepancy reports in the 
Management Control and Status Reports document and responsibility 
for resolution assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 


4 . 3 . 3 . 2 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: Design Specification — Detailed 

Assurance Specification: 

Acceptance Test Cases 

Unit Test Specifications, Procedures, and Criteria 
Quality Assurance Specifications, Procedures, 

Criteria , and Results 


52 


Release 4.3, 2/28/89 



INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION STANDARDS 
SOFTWARE: DETAILED DESIGN PHASE 


Quality Engineering Assurance Specifications, 
Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 
Criteria , and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria, and Results 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4. 3. 3. 2. 5 Phase Transition 

The Software Detailed Design Phase concludes with the successful 
completion of the Software Critical Design Review (CDR) . The 
Critical Design Review includes a formal technical review of the 
detailed design, including databases and interfaces. The 
Critical Design Review is normally accomplished for the purpose 
of establishing integrity of software design at the unit level 
prior to coding and testing. If incremental development (or 
phased delivery) is being employed in the development process, 
the Critical Design Review will be of the appropriate increment 
under development. 
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4.3.4 SOFTWARE IMPLEMENTATION PHASE 

The objectives of the Software Implementation Phase are to code 
and to unit test the software component. 

If the software component has been designed in terms of lower 
level software subcomponents, then the activities in this phase 
are analogous to those of the Information System Implementation 
Coordination Phase described in Section 4.2.4. 

If the entire software component is acquired off-the-shelf, this 
phase is used to finish procuring the software and to prepare for 
acceptance testing. 


4 . 3 . 4 . 1 Management Activities 

The collected metric information is evaluated to determine the 
status of the software. This information is used for tracking 
and, when necessary, modifying the resource estimation and other 
project attributes. Identified risk areas are re-evaluated per 
the risk assessment process defined in the Software Management 
Plan. As a result of the above, modifications and updates to 
plans are made, as required, and documented in appropriate 
Management Plans and Management Control and Status Reports 
document . 

If the software design was defined in terms of software 
subcomponents during the architectural design phase, then, as 
their life-cycles are executed, evaluation and coordination is 
conducted . 

If the entire software component is acquired off-the-shelf, then 
management support of the procurement and selection process is 
conducted during this phase. 

Management participates in the product reviews and/or evaluates 
the review and status reports to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the testing activities of the next phase 
are initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 
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4 . 3 . 4 . 2 Engineering Activities 

Implementation activities are conducted in conformance with the 
methods and approach designated in the Development Plan section 
of the Management Plan. 

If the software has been designed in terms of design elements and 
detailed design conducted to the unit level, then the engineering 
activities for this phase include code development for the 
software units. Code is documented in the Software Product 
Specification. 

If the software design is defined in terms of software 
subcomponents, then review and coordination of the lower-level 
technical activities is supported. This includes review and 
coordination of the interface specifications between the 
subcomponents, and review of their requirements and designs for 
compatibility. 

If the entire software component is acquired off-the-shelf, then 
final selection and procurement is conducted in this phase. If 
the entire software Is acquired as one delivery, then unit and 
integration testing is not required. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 


4 . 3 . 4 . 3 Assurance Activities 

Unit test specifications, procedures, criteria, test cases, etc., 
are developed, the tests conducted, and results recorded 
according to the plans specified in the Assurance Planning 
sections of the Development Plan. All unit test information is 
recorded in the Unit Test section of the Assurance 
Specification. Test reports are documented in the Management 
Control and Status Reports document. 

The remaining preparation for integration test activities, 
including test case development, is completed at this time and 
documented in the Integration Test section of the Software 
Assurance Specification. Incremental development requirements 
must be supported. 

Final preparation for acceptance testing is completed at this 
time. Including test case development. Phased delivery 
requirements must be supported. 

In addition to the review of the integration and acceptance test 
products developed in this phase, assurance activities may 
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include code walkthroughs, inspections, and audits. If this 
software has been defined in terms of software subcomponents, 
then assurance activities include the review of all the (next 
lower-level) subcomponents products. All review activities are 
documented in review reports and, if necessary, discrepancy 
reports in the Management Control and Status Reports document and 
responsibility for resolution assigned. 

If verification and validation and/or independent verification 
and validation has been specified in the Management Plan, then 
verification of the code is conducted and findings documented in 
the Assurance Specification. Any reports are documented as 
Management Control and Status Reports document verification or 
review reports. 

If verification and validation and/or independent verification 
and validation of this software is specified in the Management 
Plan for subcomponents, then some amount of verification of the 
(lower-level) subcomponents products may be conducted and 
findings documented in the Assurance Specification. In addition, 
preparation for conducting validation of this software is 
completed by the end of this phase. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 


4 . 3 . 4 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: Software Component (pre-test) 

Assurance Specification: 

Unit Tests 

Integration Test Cases 
Acceptance Test Cases 

Quality Assurance Specifications, Procedures, 

Criteria , and Results 

Quality Engineering Assurance Specifications, 

Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria, and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria, and Results 
(Independent) Verification Specifications, Procedures, 
Criteria, and Results 

(Independent) Validation Test Cases and Expected Results 
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Management Control and Status Reports: 
Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4 . 3 . 4 . 5 Phase Transition 

The Software Implementation Phase concludes with the completion 
of unit testing and peer reviews (walkthroughs, etc.) of the 
software units. 

If the software is defined in terms of subcomponents and this 
phase is an implementation coordination activity, then this phase 
concludes as subcomponents become ready for software integration 
and test (i.e., complete their Acceptance and Delivery Phase). 

If the entire software is acquired off-the-shelf, then the phase 
concludes once the software has been procured. 
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4.3.5 SOFTWARE INTEGRATION AND TEST PHASE 

The objectives of the Software Integration and Test Phase are to 
integrate the software units (or, if applicable, the software 
subcomponents) and to perform integration testing. 


4 . 3 . 5 . 1 Management Activities 

The collected metric information is evaluated to determine the 
status of the software. This information is used for tracking 
and, when necessary, modifying the resource estimation and other 
project attributes. Identified risk areas are re-evaluated per 
the risk assessment process defined in the Software Management 
Plan. As a result of the above, modifications and updates to 
plans are made, as required, and documented in appropriate 
Management Plans and Management Control and Status Reports 
document . 

Management participates in the product reviews and/or evaluates 
the review and status reports to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before the testing activities of the next phase 
are initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4 . 3 . 5 . 2 Engineering Activities 

Integration activities are conducted in conformance with the 
methods and approach designated in the Development Plan section 
of the Management Plan. The software units or (next lower-level) 
subcomponents which have passed their acceptance testing are 
integrated . 

Integration can be performed incrementally if specified in the 
Engineering and Integration section of the Development Plan and 
supported by the definition of the increments in the design 
document. Each increment undergoes integration testing assurance 
activities prior to integration with subsequent increments. If 
applicable, subcomponent providers may be required to support 
software integration. 

If the entire software component was acquired off-the-shelf as 
one delivery, then integration may not be required. 

At the completion of integration, the Version Description 
Document section of the Product Specification is prepared. 
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Final versions of the user's guide and training materials are 
developed during this phase along with the software maintenance 
manual and documented in the appropriate sections of the Software 
Product Specification. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 


4. 3. 5. 3 Assurance Activities 

At the completion of integration (for each increment if 
incremental development is used) , integration testing is 
conducted. Integration testing is often conducted by the 
engineering development team but may be performed by whatever 
organization is assigned responsibility per the Development 
Planning Section of the Management Plan. The results of all 
integration testing are documented in the appropriate test 
results section of the Assurance Specification. Any reports are 
documented in the Management Control and Status Reports 
document . 

At the completion of integration testing, the tests and their 
results are reviewed for assurance that the software component is 
ready for acceptance testing. The review results are documented 
in the Assurance Specification. Deficiencies and discrepancies 
are documented in discrepancy reports in the Management Control 
and Status Reports document and responsibility for resolution 
assigned. 

If verification and validation and/or independent verification 
and validation has been specified in the Management Plan, then 
verification of the product against the Design sections of the 
Product Specification is conducted and findings documented in the 
appropriate section of the Assurance Specification. If 
preparation for validation was not complete, it is finished and 
documented in the appropriate section of the Assurance 
Specification. Any reports are documented in the Management 
Control and Status Reports document. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the information 
system and documented in the Management Control and Status 
Reports document. 
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4 . 3 . 5 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: 

Software Component (post-integration test) 

Version Description Document 
User's Guide 
Training Materials 
Maintenance Manual 
Assurance Specification: 

Integration Test Results 

Quality Assurance Specifications, Procedures, 

Criteria , and Results 

Quality Engineering Assurance Specifications, 
Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria, and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria { and Results 
Verification Specifications, Procedures, Criteria, and 
Results 

Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4. 3. 5.5 Phase Transition 

The Software Integration and Test Phase concludes with the 
successful completion of the Test Readiness Review (TRR) of the 
software component. The Test Readiness Review is conducted to 
determine whether software acceptance test preparation is 
complete and to assure that the software component is ready for 
formal acceptance testing. A successful Test Readiness Review is 
usually predicated on the acquirer's determination that the 
acceptance test procedures and previous testing results form a 
satisfactory basis for proceeding into the Acceptance Testing 
Phase . 
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4.3.6 SOFTWARE ACCEPTANCE AND DELIVERY PHASE 

The objectives of the Software Acceptance and Delivery Phase are 
to validate that the software component meets its documented 
requirements and the users' needs and to prepare the software for 
delivery. 


4 . 3 . 6 . 1 Management Activities 

The collected metric information is evaluated to determine the 
status of the software. This information is used for tracking 
and, when necessary, modifying the resource estimation and other 
project attributes. Identified risk areas are re-evaluated per 
the risk assessment process defined in the Software Management 
Plan. As a result of the above, modifications and updates to 
plans are made, as required, and documented in appropriate 
Management Plans and Management Control and Status Reports 
document . 

Management participates in the product reviews, and/or evaluates 
the review and status reports, to determine the readiness to 
proceed to the next phase. Management is responsible for 
ensuring that all activities of this phase have been conducted 
and documented before final delivery of the software and 
initiation of the sustaining engineering activities. 

The final accept or reject decision of the software component is 
the responsibility of management. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4. 3. 6. 2 Engineering Activities 

The engineering activities include preparation of the software 
component for delivery and performing operational transition 
activities, such as training and generation of version-compatible 
User's Guide and Version Description sections of the Product 
Specification. 

Metric information (as specified in the Development Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 
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4. 3. 6. 3 Assurance Activities 

Acceptance test activities are conducted in conformance with the 
methods and approach designated in the Assurance Plan section of 
the Management Plan. The activities in this phase include formal 
testing of the software component against the requirements and 
the user scenarios. 

If phased delivery is specified, then the acceptance testing is 
conducted on the software defined for the current delivery 
against the requirements defined for that delivery. The results 
from acceptance testing are documented in the Assurance 
Speci f icat ion . 

If verification and validation and/or independent verification 
and validation is specified in the Management Plan, then the 
appropriate verification activities and all validation testing 
are conducted. Results are documented in the appropriate 
sections of the Assurance Specification. Reports are documented 
in the Management Control and Status Reports document. 

Acceptance test results and reports, along with any (independent) 
validation results and reports, are analyzed. An acceptance 
review is conducted and documented in a review report. 
Deficiencies and discrepancies are documented in discrepancy 
reports in the Management Control and Status Reports document , 
and responsibility for resolution is assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 


4 . 3 . 6 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: 

Software Component (post-acceptance test) 

Version Description (update) 

User's Guide and Training Materials (update) 
Assurance Specification: 

Acceptance Test Results 

Quality Assurance Specifications, Procedures, 
Criteria, and Results 

Quality Engineering Assurance Specifications, 
Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 
Criteria , and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria, and Results 
(Independent) Verification and Validation Results 
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Management Control and Status Reports: 
Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4. 3. 6. 5 Phase Transition 

The Software Acceptance and Delivery Phase concludes with the 
successful completion of the Functional Configuration Audit (FCA) 
and the Physical Configuration Audit (PCA) , resulting in an 
accept or reject decision. The object of the Functional 
Configuration Audit and the Physical Configuration Audit is to 
validate that the actual performance of the software component as 
determined through test complies with the requirements 
specifications, and to identify the test report (s) and data which 
document results of acceptance tests. 


Release 4.3, 2/28/89 


63 



INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION STANDARDS 
SOFTWARE: SUSTAINING ENGINEERING AND OPERATIONS PHASE 


4.3.7 SOFTWARE SUSTAINING ENGINEERING AND OPERATIONS PHASE 

The objectives of the Software Sustaining Engineering and 
Operations Phase are to sustain the operational capabilities of 
the software component, to make "repairs" and upgrades within the 
context of the original concept of the software, and to conduct 
user training and support. 

Upgrades, either outside the scope of the original concept or 
involving the major rework of the implementation, may be 
considered outside of the scope of sustaining engineering 
activities and, thus, should be addressed in the evolutionary 
acquisition of the software component. Sustaining engineering, 
as defined here, includes maintenance. 

Sustaining Engineering and Operations is often conducted at the 
information system level. In such case, sustaining engineering 
of the software component will be conducted from the delivery of 
the software to the acquirer (i.e., the information system at the 
next hiqher level in system decomposition) until the information 
system itself enters its sustaining engineering and operations 
phase. Support to sustaining engineering and operations of the 
the information system may be required of the software 
component . 


4.3.7. 1 Management Activities 

Review and approval of discrepancy reports and change proposals 
is conducted by management. Modifications and updates to plans 
are made and documented in appropriate Management Plans. Plans 
for change incorporation must adhere to the same acquisition and 
assurance requirements as originally identified for the software 
component classification level. 

Management participates in the product reviews, and/or evaluates 
the review and status reports, to determine the readiness to 
deliver the next release of the software. Management is 
responsible for ensuring that all activities of this phase are 
conducted and documented. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 
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4. 3. 7. 2 Engineering Activities 

Technical evaluation of discrepancy reports and change proposals 
is performed. Changes to the software component are only 
implemented based on approved change requests. This requires 
iteration through the requirements, design, implementation, and 
testing phases of the life-cycle. The activities defined in 
those phases are performed, resulting in updates to the specified 
products . 

In addition to supporting the operations of the information 
system, user and operator training may be required as an on-going 
services . 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 


4.3.7. 3 Assurance Activities 

To maintain the integrity and quality of the software component, 
the same types and levels of assurance must be conducted during 
sustaining engineering as were performed during development 
(i.e., previous phases of the life-cycle). Reviews of all 
updated products are conducted and documented in review reports. 
Acceptance testing, verification and validation, and independent 
verification and validation activities are performed, as 
specified in the Management Plan. Regression testing is 
performed to assure that operational integrity is maintained. 
Test results are documented in the Assurance Specification. 

If required by software changes, modification to specifications, 
criteria, test cases, and expected results may be made. This 
will require updates to the Assurance Specification. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the software and 
documented in the Management Control and Status Reports 
document . 
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4 . 3 . 7 . 4 Product Summary 

Management Plan: Updates 

Product Specification: Updates 

Assurance Specification: Updates 

Management Control and Status Reports: 
Discrepancy Reports 
Engineering Change Proposals 
Status Reports 
Review Reports 
Performance/Metrics Reports 


4 . 3 . 7 . 5 Phase Transition 

The Software Sustaining Engineering and Operations Phase 
concludes with the retirement of the software (or the information 
system of which the software is a component) or the transition to 
its next evolutionary phase. 

Reviews conducted during the Sustaining Engineering and 
Operations Phase are dependent upon the types of changes 
required. Sustaining Engineering requires revisiting life-cycle 
phases. For each life-cycle phase revisited, the appropriate 
phase transition reviews are conducted. 
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4.4 Hardware Life-Cycle Definition 

The hardware life-cycle consists of the following phases: 

Hardware Concept and Initiation 
Hardware Requirements 
Hardware Design 

- Architectural Design 

- Detailed Design 
Hardware Fabrication 
Hardware Integration and Test 
Hardware Acceptance and Delivery 

Hardware Sustaining Engineering and Operations (Support) 

This life-cycle usually is initiated for each hardware 
component. The hardware life-cycle is presented here in terms of 
variations from the information system life-cycle. In general, 
independent verification and validation, certification, and 
evolutionary acquisition activities are only conducted at the 
information system level, not at the component level. Therefore, 
activities and products related to these may not be applicable to 
hardware. In addition, sustaining engineering and operations may 
be conducted on the system as a whole; in such cases, the 
hardware provider supports this system level activity. 


4.4.1 HARDWARE CONCEPT AND INITIATION PHASE 

The objective of the Hardware Concept and Initiation Phase is 
analogous to the corresponding information system life-cycle 
phase . 

Some of the activities for this phase may not be required due to 
their previous execution at higher nodes in the system 
decomposition. The hardware concept may have been fully defined 
at a higher level. Management planning for the Acquisition 
Planning section may be able to reference sections in 
higher-level documentation. 

In this phase and all subsequent phases of the life-cycle: 
o Lessons learned reports are completed 

o Adherence to the life— cycle and documentation standards 
contained herein must be assured 

o All products, including updates to previously baselined 

products, are placed under configuration management prior to 
their review 
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4.4.2 HARDWARE REQUIREMENTS PHASE 

The objective of the Hardware Requirements Phase is analogous to 
the corresponding information system life-cycle phase. The 
hardware component activities and products for management, 
engineering, and assurance may differ from the information system 
activities in the following: 

o Sustaining Engineering and Operations may be a system level 
activity, but supported by the hardware component 

o Requirements are traceable to the next higher level design, 
either information system or hardware 

The successful completion of the Requirements Review for hardware 
triggers transition to the next phase. 

As with the Concept and Initiation phase, the management 
activities may result in references to sections in higher level 
documentation . 


4.4.3 HARDWARE DESIGN PHASE 

The Hardware Design Phase may be partitioned into two subphases, 
architectural design and detailed design, with a phase transition 
review at the conclusion of each. 


4. 4. 3.1 Architectural Design 

The objective of the Hardware Architectural Design Phase is 
analogous to the Information System Design Phase. During this 
phase the architecture of the hardware is developed. The 
activities and products for management, engineering, and 
assurance may differ in the following: 

o If the hardware or portions of the hardware is to be 
acquired off-the-shelf, then selection and procurement 
preparation is conducted in this phase 

o The design decomposition can only be into hardware sub- 
components or into hardware design elements 

o Reuse/commonality and buy/build/modify plans for hardware 
are developed 

o This phase is concluded with the successful completion of 
the Hardware Preliminary Design Review (PDR) 

If the hardware design is specified in terms of lower level 
hardware subcomponents, then this hardware component enters an 


68 


Release 4.3, 2/28/89 



INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION STANDARDS 

HARDWARE: DESIGN PHASE 


implementation coordination phase (analogous to the information 
system implementation coordination phase) and life-cycles are 
instantiated for each hardware subcomponent. The requirements 
for this hardware component are allocated to the hardware 
subcomponents . 

If the hardware design is specified in terms of hardware design 
elements (rather than major subcomponents), than this hardware 
component enters the detailed design phase, followed by the 
fabrication phase. 


4. 4. 3. 2 Detailed Design 

The Hardware Detailed Design Phase is not directly analogous to 
any phase in the information system life-cycle. The objective of 
the Hardware Detailed Design Phase is to continue the design 
process to the assembly and unit level in preparation for 
hardware fabrication. The activities in this phase are only 
conducted at the lowest hardware component level of the 
decomposition tree and are dependent on buy/build/modify 
decisions . 


4. 4. 3. 2.1 Management Activities 

The collected metric information is evaluated to determine the 
status of the hardware component. This information is used for 
tracking and, when necessary, modifying the resource estimation 
and other project attributes. Identified risk areas are 
re-evaluated per the risk assessment process defined in the 
Management Plan. Planning modifications and updates are made, as 
required, and documented in appropriate Management Plans and 
Management Control and Status Reports document. 

If the hardware or portions of the hardware are to be acquired 
off-the-shelf, then selection and procurement preparation is 
conducted in this phase. 

Participation in the product reviews, or evaluation of the review 
and status reports, is conducted by management to determine the 
readiness to proceed to the next phase. It is the responsibility 
of management to ensure all activities (engineering and 
assurance) of this phase have been conducted and documented 
before the fabrication activities of the next phase are 
initiated. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 
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4. 4. 3. 2. 2 Engineering Activities 

Detailed design activities are conducted in conformance with the 
methods and approach designated in the Development Planning 
section of the Management Plan. 

Hardware detailed design to the unit level is conducted during 
this phase for each hardware assembly. This design is documented 
in the Detailed Design section of the Hardware Product 
Specification. 

Buy/build/modify decisions are made in this phase and any 
necessary procurement activities conducted. Incremental 
development and phased delivery decisions affect the scope of the 
design activity. 

If the entire hardware component is acquired off-the-shelf as a 
single package, then detailed design activities, unit test 
development, and integration testing may be omitted. (The 
implementation phase would consist of final procurement 
activities in preparation for acceptance testing.) 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the hardware 
component and documented in the Management Control and Status 
Reports document. 


4. 4. 3. 2. 3 Assurance Activities 

If the hardware is developed (rather than purchased 
off-the-shelf) , then hardware unit test specifications, 
procedures, and criteria are generated and documented in the Unit 
Test section of the Assurance Specification. 

If the hardware component is acquired off-the-shelf as a single 
package, then the hardware acceptance test cases are prepared in 
this phase as the integration testing activity is not required. 

Other assurance activities as specified in the Assurance Planning 
section of the Management Plan are conducted, including reviews 
of the engineering and assurance products developed in this 
phase. Findings are documented in the Assurance Specification. 
Deficiencies and discrepancies are documented in discrepancy 
reports in Management Control and Status Reports document, and 
responsibility for resolution assigned. 

Metric information (as specified in the Management Plan) is 
collected for the tracking and evaluation of the hardware 
component and documented in the Management Control and Status 
Reports document. 
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4 . 4 . 3 . 2 . 4 Product Summary 

Management Plan: Plan Updates 

Product Specification: Design Specification — Detailed 

Assurance Specification: 

Unit Test Specification, Procedures, and Criteria 
Quality Assurance Specifications, Procedures, 
Criteria, and Results 

Quality Engineering Assurance Specifications, 
Procedures, Criteria, and Results 
Safety Assurance Specifications, Procedures, 

Criteria , and Results 

Security and Privacy Assurance Specifications, 
Procedures, Criteria, and Results 
Acceptance Test Cases 
Management Control and Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 


4. 4. 3. 2. 5 Phase Transition 

The Hardware Detailed Design Phase concludes with the successful 
completion of the Hardware Critical Design Review (CDR) . The 
Critical Design Review is a technical review of the detailed 
design including interfaces. If the hardware is being developed 
incrementally, then the Critical Design Review is only for the 
current increment and its interfaces with existing increments. 


4.4.4 HARDWARE FABRICATION PHASE 

If the hardware's design is specified in terms of hardware 
subcomponents or is acquired as a single off-the-shelf package, 
then the objective of this phase is similar to the to the 
implementation coordination phase in the information system 
life-cycle. 

If the hardware is being developed (i.e., built or modified), 
then the objective of this phase is to build the hardware 
component. Additional activities conducted in this phase for the 
development of the hardware component include: 

o Hardware is produced from the detailed design and documented 
in the Product Specification 

o Unit inspections and audits are conducted and documented in 
the appropriate review reports of the Management Control and 
Status Reports document 
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o Unit test cases are developed; tests are conducted and the 
results documented in the Assurance Specification 

This phase concludes with peer reviews of the tested units . 


4.4.5 HARDWARE INTEGRATION AND TEST PHASE 

The objective of the Hardware Integration and Test Phase is 
analogous to the corresponding information system life-cycle 
phase. The activities and products for management, engineering, 
and assurance may differ in the following: 

o A Hardware Maintenance Manual is developed 

o Hardware units and/or acquired hardware packages are 
integrated, and integration testing is performed 

o The product of this phase is the hardware component 

Preliminary integration testing with other hardware components or 
software components (or against the interface design) at the same 
(or possibly higher) level in the information system 
decomposition tree (i.e. horizontal integration) , although not 
required, is recommended during this phase or the following phase 
in preparation for system integration testing. 


4.4.6 HARDWARE ACCEPTANCE AND DELIVERY PHASE 

The objective of the Hardware Acceptance and Delivery Phase is 
analogous to the corresponding information system life-cycle 
phase . 

Final acceptance of the hardware component may be contingent upon 
proof that the component can be successfully integrated into the 
information system (or higher level hardware component depending 
on the decomposition tree) . 


4.4.7 HARDWARE SUSTAINING ENGINEERING AND OPERATIONS PHASE 

After acceptance and delivery of the hardware, sustaining 
engineering and operations support to the information system may 
be required. Sustaining Engineering and Operations may be 
conducted only at the information system node once the 
information system has reached that phase in its life-cycle. 
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4.5 Operational Procedures Life-Cycle 

Operational Procedures are the manual procedural aspects of the 
information system (usually conducted by an "operator") which 
complement the hardware and software of an information system. 

Early definition, interoperability with hardware and software, 
and implementation of these operational procedures are critical 
to the effectiveness of the information system. This section 
describes the management, engineering, and assurance activities 
necessary to support to the definition and assurance of these 
operational procedures. 

The operational procedures life-cycle consists of the following 
phases : 

Operational Procedures Concept and Initiation 

Operational Procedures Requirements 

Operational Procedures Design 

Operational Procedures Implementation 

Operational Procedures Evaluation and Training 

Operational Procedures Sustaining Engineering and Operations 

This life-cycle is instantiated for each operational procedures 
component. The operational procedures life-cycle is presented 
here in terms of variations from the information system 
life-cycle. In general, independent verification and validation, 
certification, and evolutionary acquisition activities are only 
conducted at the information system level, not at the component 
level. Therefore, activities and products related to these may 
not be applicable to operational procedures. In addition, 
sustaining engineering and operations may be conducted on the 
system as a whole; in such cases, the operational procedures 
provider supports this system level activity. 


4.5.1 OPERATIONAL PROCEDURES CONCEPT AND INITIATION PHASE 

The objective of the Operational Procedures Concept and 
Initiation Phase is analogous to the corresponding information 
system life-cycle phase. 

Some of the activities allocated to this phase may not be 
required due to their previous execution at higher nodes in the 
system decomposition. The operational procedures concept may 
have been fully defined at a higher level. Management planning 
may be able to reference sections in higher-level documentation. 

In this phase and all subsequent phases of the life-cycle: 

o Lessons learned reports must be completed 
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o Adherence to the life-cycle and documentation standards 
contained herein must be assured 

o All products, including updates to previously baselined 
products, are placed under configuration management prior 
to their review 


4.5.2 OPERATIONAL PROCEDURES REQUIREMENTS PHASE 

The objective of the Operational Procedures Requirements Phase is 
analogous to the corresponding information system life-cycle 
phase. The operational procedures component activities and 
products for management, engineering, and assurance may differ 
from the information system activities in the following: 

o Sustaining Engineering and Operations may be a system level 
activity, but supported by the operational procedures 
component 

o Requirements are traceable to the next higher level design 

As with the Concept and Initiation phase, some of the management 
activities may result in references to sections in higher level 
documentation . 


4.5.3 OPERATIONAL PROCEDURES DESIGN PHASE 

The objective of the Operational Procedures Design Phase is 
similar to the Information System Design Phase. The operational 
procedures component activities and products for management, 
engineering, and assurance may differ from the information system 
activities in the following: 

o Commonality plans for procedures are developed 

o Detailed design of the procedures is performed 

o Manual procedures specified for hardware and software are 
incorporated into the design of the operational procedures 


4.5.4 OPERATIONAL PROCEDURES IMPLEMENTATION PHASE 

The objective of the Operational Procedures Implementation Phase 
is to develop the operational procedures manual for the 
information system. Activities include: 

o Procedures are developed from the detailed design and 

documented in the operational procedures manual section of 
the Product Specification 
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o Walkthroughs are conducted and documented in the appropriate 
Assurance Specification and review reports of the Management 
Control and Status Reports document 

o Inspections and audits may be conducted and documented 
in the appropriate Assurance Specification and review 
reports of the Management Control and Status Reports 
document 

The products of the Operational Procedures Implementation Phase 
are: the manual containing the procedures for the operators of 

the information system, the Version Description section, and 
training materials and users' guide sections of the Product 
Specification. 


4.5.5 OPERATIONAL PROCEDURES EVALUATION AND TRAINING PHASE 

The objectives of the Evaluation and Training phase are to 
evaluate the correctness and effectiveness of the procedures and 
to conduct training on operational use. 


4 . 5 . 5 . 1 Management Activities 

Identified risk areas are re-evaluated per the risk assessment 
process defined in the Information System Management Plan. As a 
result, modifications and updates to plans are made, as required, 
and documented in appropriate Management Plans and Management 
Control and Status Reports document. 

Management participates in the product reviews, or evaluates the 
review and status reports, to determine the readiness to proceed 
to the next phase. Management is responsible for ensuring that 
all activities of this phase have been conducted and documented 
before final delivery. 

If discrepancy reports or change proposals are generated in this 
phase, management is responsible to ensure they are dispositioned 
and responsibility for resolution assigned. 


4. 5. 5. 2 Engineering Activities 

The engineering activities include final preparation of the 
procedures for delivery and performing operational transition 
activities, such as operator and user training. 
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4 . 5 . 5 . 3 Assurance Activities 

The assurance activities in this phase include evaluation of the 
procedures against the requirements, including "testing" and 
assurance activities specified in the Management Plan. 

Reviews are conducted periodically throughout the Evaluation and 
Training Phase and are documented in a review report. 
Deficiencies and discrepancies are documented in discrepancy 
reports, and responsibility for discrepancy resolution is 
assigned. 


4 . 5 . 5 . 4 Product Summary 

Management Plan: Updates 

Product Specification: 

Operational Procedures Manual (post-evaluation) 
Version Description Document 
Operators Manual and Training Materials 
Assurance Specification: 

Evaluation Specifications, Procedures, Criteria, and 
Results 

(Independent) Verification and Validation Results 
Management Control Status Reports: 

Lessons Learned 
Review Reports 
Status Reports 
Discrepancy Reports 
Engineering Change Proposals 
Performance/Metrics Reports 


4. 5. 5. 5 Phase Transition 

The Operational Procedures Evaluation and Training Phase 
concludes with the successful completion of the Operational 
Procedures Acceptance Review, resulting in an accept/ reject 
decision. 


4.5.6 OPERATIONAL PROCEDURES SUSTAINING ENGINEERING AND 
OPERATIONS PHASE 

After acceptance and delivery of the operational procedures, 
sustaining engineering and operations support to the information 
system may be required. Sustaining Engineering and Operations 
may be conducted only at the information system node once the 
information system has reached that phase in its life-cycle. 
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4.6 Life-Cycle Documentation Products 

Prior to the implementation phase of the life-cycle, most 
products are documents. The purpose of the documentation is to 
record information concerning the activities and decisions of 
that phase. There are four basic documents defined as the 
documentation set for each information system and each component 
in the system decomposition tree. The four basic documents are: 

o Management Plan 
o Product Specification 
o Assurance Specification 
o Management Control and Status Reports 

The four basic documents can be supplemented with a "repository" 
of project-specific standards, procedures, and practices for such 
things as network protocols, graphics, and programming 
conventions . 

In general, each document relates directly to a category of 
activities defined in the life-cycle definitions. Management 
activities are documented in the management plan; engineering 
activities in the product specification, and assurance 
(technical) activities in the assurance specification. The 
management control and status reports document is intended to 
provide an organization and logical home for all reports - 
management, engineering, and assurance. In general, the reports 
are written for management. 

Each document in the document set may consist of one or more 
volumes. A mechanism called roll-out is used to define the 
organization of subordinate volumes while ensuring traceability. 
Figure 4-3 presents an example of roll-out. 

The amount of information to be documented, and hence the number 
and size of physical volumes, is determined by program/project 
management . 
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Figure 4-3. Example of Roll-Out of Document 
Sections into Volumes. 
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The actual documentation standards, associated rules, and the 
detailed Data Item Descriptions (DIDs) for the four document 
types are presented in volumes rolled-out from this document. 
The four volumes are: 


o Management Plan Documentation Standard and Data Item 
Descriptions 

o Product Specification Documentation Standard and Data 
Item Descriptions 

o Assurance Specification Documentation Standard and Data 
Item Descriptions 


o Management Control and Status Reports Documentation 
Standard and Data Item Descriptions 

The major sections of each of the four documents is presented in 
the table below. Figures 4-4, 4-5, and 4-6 present the timeline 
for generation of these sections against the life-cycle. 


MANAGEMENT PLAN 

Acquisition 

Development 

Sustaining Engineering and Operations 
Evolutionary Acquisition 

PRODUCT SPECIFICATION 

Concept 

Requirements 

Design 

Version Description 

User and Operator Documentation 

Maintenance Manual 

ASSURANCE SPECIFICATION 

Quality Assurance 
Testing 

Quality Engineering Assurance 

Safety Assurance 

Security and Privacy Assurance 

Verification and Validation 

Certification 

MANAGEMENT CONTROL AND STATUS REPORTS 
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Figure 4-4. Management Plan Timeline. 
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Figure 4-5. Product Specification Timeline. 
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4.7 Phase Transition Reviews 

An essential part of the life-cycle model is the phase transition 
reviews. A phase transition review occurs at the end of each 
phase. As the sustaining engineering process is an iteration of 
the activities of previous life-cycle phases, these phase 
transition reviews must also be conducted as part of the 
sustaining engineering process. The major purposes of the phase 
transition reviews are to provide a focal point for: 1) the 

assurance activities associated with the current phase, and 2) 
the update of the management plan for the next phase. Figure 4-7 
lists the phase transition reviews associated with each phase. 

A phase transition review almost always produces a number of 
discrepancy reports and action items. If the number and 
criticality of issues to be resolved is low, then activities of 
the subsequent phase may be initiated in parallel with rework for 
the current phase. When the rework is complete, an informal 
review should be conducted to ensure the adequacy of the rework. 

If the number or criticality of issues to be resolved is high, 
then major activities for the current (and possibly previous) 
phase may need to be repeated. No activities for the subsequent 
phase are initiated. A "delta" phase transition review should be 
conducted to ensure that all issues have been properly resolved. 

The Assurance Planning sections of the Management Plan identify 
the review process and the responsible organizations . The review 
criteria and other technical specifications of the reviews 
including the results are documented in the Assurance 
Specification. Reports to management concerning the reviews are 
documented in the Management Control and Status Reports 
document. The review process, criteria, responsible 
organizations, and other descriptive details of phase transition 
reviews are dependent upon the assurance plans and assurance 
specifications for the information system or component under 
review. It is the responsibility of management to define, 
schedule, and execute these reviews. 
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Figure 4-7. Component Life-Cycle Review Variations. 
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4.8 Life-Cycle and Documentation Rules 

For each information system, for each subordinate information 
system (subsystem) , and for each hardware, software, and 
operational procedures component identified as a node in the 
information system decomposition tree, the following rules shall 
apply: 

1) A life-cycle shall be instantiated and shall conform to 
the appropriate life-cycle model defined in Section 4.2, 

4.3, 4.4, or 4.5. The description of the instantiation 
shall be contained in the management plan for that 
information system or component. 

2) Each instantiated phase shall end with a phase transition 
review. The results of such a review shall be prepared and 
placed in the Assurance Specification document. 

3) A documentation set of four documents shall be prepared for 
each information system and component. This set shall con- 
sist of a management plan, a product specification, an 
assurance specification, and a management control and status 
reports document. 

The following rules associated with life-cycle determination and 
documentation shall apply: 

1) Assurance activities shall be successfully accomplished 
before making the transition from the current phase to 
the next phase of the life-cycle. 

2) The management plan shall be updated and reviewed as a 
necessary transition from the current phase to the next 
phase of the life-cycle. 

3) The management plan shall define the roles and responsibi- 
lities of the acquirer's and providers' organizations. 

4) The management, engineering, and assurance processes defined 
in the Management Plan shall be followed throughout the 
instantiated life-cycle. 

Specific documentation standards and associated rules for the 
documentation set are contained in Section 4 of the four rolled- 
out volumes referenced in Section 2.2. 
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5.0 APPLICATION AND SUPPORT OF THE LIFE-CYCLE AND DOCUMENTATION 
STANDARDS 

The guidelines supporting the documentation standards are 
contained in Section 5.1 of the four rolled-out volumes of this 
document (referenced in Section 2.2). 


5.1 Guidelines for the Application of the Life-Cycle Standard 


5.1.1 How to Instantiate a Life-Cycle 

The life-cycles are defined in Section 4 as serial processes with 
precise boundaries and each phase occurring only once. While a 
simple information system or component can be acquired or 
developed in that manner, the large and complex systems that 
comprise the majority of the information systems or large, 
complex components require adaptations to these life-cycle 
models. 

An initial version of the life-cycle instantiation is prepared 
early in the concept and initiation phase. When instantiating a 
life-cycle for a specific node (system or component) , the system 
decomposition tree defined to that node must be taken into 
consideration. The life-cycle being instantiated must conform to 
the life-cycle definitions and adaptations, standards, schedules, 
and milestones, etc. of parent nodes in the system decomposition 
tree, as defined in the documentation sets for these parent 
nodes. The constraints imposed by these parent nodes must be 
considered during the instantiation of the life-cycle for this 
node. 

Using the life-cycle model, phases that are appropriate to the 
development or procurement of the information system or component 
are determined. Often there are substantial iterations during 
the development of an information system or component. Sections 

5.1.2 through 5.1.4 describe common life-cycle adaptations to 
support different types of iteration. 

The instantiation of the life-cycle determines the gross level 
schedule and milestone layout (or vice versa) . The actual phases 
and scheduling of the life-cycle impacts the work breakdown 
structure, reviews, schedules, and milestones for the node. 
Conversely, changes in the management plan can require changes in 
the instantiation of the life-cycle model. The description of 
the specific, adapted life-cycle to be used is documented in the 
management plan. 
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5.1.2 Phased Delivery Adaptation 

Information system or component development often requires 
supplying multiple deliveries, usually with increasing 
capability, to the acquirer (or next higher level information 
system or component) . Each delivery must pass the acceptance 
testing for that delivery prior to its release. This procedures 
is termed "phased delivery" and requires multiple iterations 
through many of the life-cycle phases. Figure 5-1 presents an 
example of the life-cycle model adapted for phased delivery of a 
software component. 

The purpose of the phased delivery adaptation is to get some 
capabilities to the users (or next higher level information 
system or component) as early as possible. Each delivery should 
provide increased capability to the user. In general, for phased 
delivery, the scope and all requirements for the information 
system or component are defined during the requirements phase, 
though these may get refined later in the life-cycle through 
discrepancy reports and change proposals from users. Phased 
delivery reguires that sustaining engineering and operations 
support begin at the time of the first delivery. 


5.1.3 Incremental Development Adaptation 

When the concept of "code a little, test a little" is desired to 
be employed within the development organization, the life-cycle 
may require an incremental development adaptation. The purpose 
of the incremental adaptation is to avoid the "big bang" approach 
to development and integration in which an attempt is made to 
integrate the entire information system or component at one 
time. In this adaptation, a single delivery of the information 
system or component is delivered to the users but that delivery 
is developed in increments. The architectural design is 
partitioned into specific increments. Each increment provides a 
predefined, but not necessarily complete, set of functional 
capabilities. An example of an adaptation of the basic software 
life-cycle for incremental development is shown in Figure 5-2 . 

A principal benefit of incremental development is that it 
provides visibility into the development to assess progress. 
Incremental development has been shown to decrease risk and to 
increase reliability and productivity in the development 
process. Therefore, use of incremental development is 
encouraged, even when phased delivery requirements also exist. 
Managers should be advised, though, that this can increase the 
configuration management support required during the development 
process . 
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Figure 5-1. Example of a Software Component Phased Delivery 

Adaptation . 
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Figure 5-2. Example of a Software Component Incremental Development 

Adaptation. 
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Incremental development also can be used in conjunction with 
prototyping to focus on components or systems that have a high 
risk factor or are critical, or to explore alternative design and 
implementation approaches . 

Incremental development is often used in conjunction with phased 
delivery; i.e., each delivery is developed incrementally. This 
requires partitioning of the requirements for phased delivery and 
of the design (consistent with the requirements partitioning) for 
incremental development. The combining of these adaptations 
requires detailed planning and a configuration management 
process . 


5.1.4 Evolutionary Acquisition Adaptation 

Evolutionary acquisition refers to multiple passes through the 
entire life-cycle for a specific information system or 
component. It usually refers to major upgrades to an information 
system or component for which major portions of the existing 
system may be used as inheritables. Evolutionary acquisition is 
usually only feasible for long-life systems for which new 
feasibility study and procurement activities are conducted. 
Requirements for the next evolution of a system or component are 
usually not known until after the current system or component has 
been in use for some time. 


5.1.5 Interactions Between Life-Cycle Phases 

While each phase usually has a distinct event that marks the end 
of the phase, the beginning of a phase does not usually wait for 
the completion of the previous phase. Often there exists a 
build-up period beginning during the previous phase and a 
phase-down period to work any action items or discrepancies from 
the reviews and other assurance activities of the phase. For 
example, the provider may begin the work of the next phase while 
the products of the previous phase are still in distribution for 
final review and comment. An example of such an adaptation is 
shown in Figure 5-3. 

Note that while efforts may be started before the formal 
baselining of the products of the previous phase, the early start 
carries the risk that what is done may need to be redone as a 
result of the decisions resulting from the phase transition 
review at the end of the previous phase. Thus only areas where 
virtually little or no change is anticipated should be started 
early. The provider is held responsible for any cost or schedule 
growth resulting from early start of work having to be redone due 
to changes made during the completion process of the previous 
phase . 
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5.1.6 Interactions Among Life-Cycles 

The life-cycle presented in this document is designed to 
accommodate a system decomposition methodology. (See concepts 
presented in Section 3.4 of this document.) Based on that 
approach, information systems (or components) can impose 
life-cycle adaptation requirements on systems or components at 
lower levels in the decomposition. The interaction may become 
guite involved. For example, if an information system plans to 
incorporate incremental development into its development 
approach, then that may impose phased delivery requirements on 
its subsystems or components. The development manager must take 
this into consideration when determining the development approach 
and life-cycle adaptations to be employed in the development of a 
particular information system or component. An example of 
life-cycle interactions is depicted in Figure 5-4. 


5.1.7 Adaptation for Prototyping 

Certain techniques, especially if used in parallel to the 
production development, can impact the life-cycle adaptation. 

The development manager must determine what techniques are to be 
used in the development of the information system or component, 
determine exactly how these techniques are to be used, establish 
how these affect the life-cycle and products, and document this 
in the Development Plan section of the Management Plan. 

For example, prototyping is a technique that can be useful in a 
number of different ways. It can be used for requirements 
analysis or for design trade-offs. It can involve evaluation by 
users or by the development team of various models of parts of 
the system or component. In any event, the use of a technique, 
such as prototyping, should tie back into the goals and products 
for the phase in which it is being used. 

Prototyping is defined within the scope of this standard as a 
process {or method) used within the life-cycle to assess and/or 
reduce risk or to gain knowledge. Categories of prototypes 
sometimes referred to as interim or final are considered forms of 
phased delivery or incremental development and are covered under 
adaptation of the life-cycle for those development approaches. 
Categories of prototyping recognized within this standard (such 
as conceptual, functional, or performance) reflect either in 
which phase prototyping is being used or for which risk or 
knowledge area this activity is being performed. 

How and when prototyping, or any other technique, is to be used 
for the development of an information system or component and any 
required adaptation of the life-cycle activities, products, and 
reviews is the responsibility of the development manager and is 
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Figure 5-4. Life-Cycle Interaction Example. 




























INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION STANDARDS 
APPLICATION AND SUPPORT OF THE STANDARDS 


documented in the Development Plan section of the Management Plan 
for that particular information system or component. 

Prototyping as a process can be used anywhere within the 
life-cycle. It is usually used within a phase as a process or 
method used in engineering of the products of that phase . The 
prototyping process consists of three steps: Definition and 

Planning; Execution and Analysis; and Evaluation. The product of 
the prototyping process is a report, the results of which may be 
used within the products of that phase. The prototyping process 
may produce a number of by-products, including software, 
hardware, models, and systems. The re-use of any by-products 
(and their subsequent assurance, etc.) is a management issue and 
should be addressed in the management plan. 

Activities of the Definition and Planning step of the prototyping 
process include specification of the risk, need, or issue to be 
addressed; formal statement of the problem; definition of 
expectations; specification of the evaluation criteria; and 
definition of the techniques to be used to perform the 
prototyping. 

Activities of the Execution and Analysis step include selection 
and preparation of specific methods to be used to perform the 
prototyping process; execution, i.e., the simulation, emulation, 
etc. ; and analysis of the results against the criteria. The 
Evaluation step is used to document the results of the analysis 
and of the prototyping process and present any trade-offs and 
recommendations . 

Prototyping is a risk assessment and analysis method that may be 
applied within any phase of the life-cycle. Use of prototyping 
may be established early in the software life-cycle when trade 
analysis and risk conditions are > identified. Or a decision to 
use prototyping may arise later in the life-cycle based the 
introducton of new technology or of a risk factor. In either 
event, the plan and goal of the prototyping activity should be 
defined within the management plan and the evaluation and results 
in a management control and status report. If the prototyping 
activity is a major effort, involving the development and/or 
procurement of a large hardware/software facility, then the 
facility should have its own development plan and related product 
and assurance specifications. 


94 


Release 4.3, 2/28/89 



INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION STANDARDS 
APPLICATION AND SUPPORT OF THE STANDARDS 


5.1.8 Adaptations for COTS 

When an information system or component (or part thereof) is 
procured as a commercial -off-the-shelf (COTS) item, the 
instantiated life-cycle may be substantially abbreviated. In the 
optimum situation, when the entire system or component is 
procured off-the-shelf, only the following three phases might be 
required : 

1) Concept and Initiation 

2 ) Requirements 

3) Acceptance and Delivery 

In this adaptation, though { some activities identified in other 
life-cycle phases must be incorporated into these phases. 

In the Concept and Initiation Phase, the need is scoped and based 
upon a quick inventory of the commercial marketplace, a decision 
is reached whether one or more commercial packages are available 
to meet the needs and that the selection of such a package is the 
best solution. 

If the decision is negative (i.e., a COTS solution is not 
feasible) , then a typical development process life-cycle must be 
defined and initiated. If the decision is positive (i.e., a COTS 
solution is feasible) , then the Requirements Phase is begun. 
During . the . Requirements Phase, specifications for the procurement 
and criteria for the selection are developed, and a procurement 
process started and completed. Also, the acceptance test 
specifications, test cases, etc. are developed. 

In the Acceptance and Delivery Phase, acceptance tests are 
conducted on the COTS item and, if successful, the item is 
accepted for delivery. Any training, if necessary, should be 
part of the delivery process and, therefore, the procurement. In 
this ' example, it is assumed that no sustaining engineering is 
required and that operations are either conducted by the acquirer 
or are a part of the activities of an encompassing information 
system or component. 

Of course, the adaptation of the life-cycle model for a COTS 
procurement might be more involved. For example , the decision to 
obtain a commercial package might not be made until the Design 
Phase or a COTS item may be only one element of an information 
system or component. The important point is that the life-cycle 
model is adaptable to a wide range of applications including a 
COTS procurement. In adapting the life-cycle for a specific 
implementation, all life-cycle activities must be considered for 
their applicability. 
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5.2 Tools Supporting the Application and Use of the Life-Cycle 
and Documentation Standards 

Management and engineering automated support environments may 
provide tools for the application and use of these standards. 
Tool support of these standards is the responsibility of the 
program/pro j ect . 
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6.0 ASSURANCE AND ENFORCEMENT OF THE LIFE-CYCLE AND 
DOCUMENTATION STANDARDS 

If the SMAP information system life-cycle and documentation 
standards have been selected by program/pro j ect management as 
standards < for an information system or component, then it is the 
responsibility of program/project management to assure and 
enforce these standards. 

The standards assurance and enforcement process is an integral 
part of the assurance process for the information system or 
component . This process is addressed in the following ways: 

1) As the assurance sections of the management plan are being 
prepared, proper emphasis should be applied to the enforce- 
ment and interpretation process of the standards. 

2) When the selection and ordering of the phases for the 
instantiation of the life-cycle model is being reviewed, 
the life-cycle model provides a checklist for the re- 
viewers . 

3) As a quality assurance activity during the phase transition 
reviews indicated by the instantiation of the life-cycle 
model. 

4) As explicitly called for within any assurance section of a 
plan. For example, the assurance planning section of the 
management plan could call for a special review at the end 
of the implementation phase to verify that all documentation 
was prepared according to the SMAP documentation standards. 

It is the responsibility of any reviewer to be familiar with the 
particular aspects of the life-cycle and documentation standards 
that are applicable to the products or process (es) under review 
and to question any deviations from those standards. 

The life-cycle model and detailed outline and contents 
specifications for documentation can be used by reviewers as a 
gross level checklist. 


Release 4.3, 2/28/89 


97 



INFORMATION SYSTEM LIFE-CYCLE AND DOCUMENTATION STANDARDS 

ABBREVIATIONS AND ACRONYMS 


7.0 ABBREVIATIONS AND ACRONYMS 

AR - Acceptance Review 

CDR - Critical Design Review 

COTS - Commercial off-the-shelf 

DID - Data Item Description 

DoD - Department of Defense 

DRL - Data Requirements List 

ECP - Engineering Change Proposal 

EPROM - Erasable Programmable Read-Only Memory 

FCA - Functional Configuration Audit 

FMEA - Failure Modes and Effects Analysis 

GFE - Government-furnished equipment 

IV&V - Independent Verification and Validation 

LRU - Line (or Lowest) Replaceable Unit 

MTBF - Mean Time Between Failures 

MTTR - Mean Time to Repair 

NASA - National Aeronautics and Space Administration 
NHB - NASA Handbook 

NRCA - Nonconformance Reporting and Corrective Action 

PCA - Physical Configuration Audit 

PDR - Preliminary Design Review 

PROM - Programmable Read-Only Memory 

RFP - Request for Proposal 

RID - Review Item Discrepancy 

ROM - Read-Only Memory 

RR - Requirements Review 
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SMAP - Software Management and Assurance Program 
SOW - Statement of Work 

SRM&QA - Safety, Reliability, Maintainability, and Quality 
Assurance 

SSE - Software Support Environment of the Space Station Freedom 
Program 

SSFP - Space Station Freedom Program 
STD - Standard 

TBD - To be determined (at a later date) 

TMIS - Technical and Management Information System of the Space 
Station Freedom Program 

TRR - Test Readiness Review 

V&V - Verification & Validation. 

WBS - Work Breakdown Structure 
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8 . 0 GLOSSARY 

For terms not appearing in this glossary, refer to the IEEE Stan- 
dard Glossary (as referenced in Section 2.2). 


Acceptance Review - The phase transition review for the Acceptance 
and Delivery life-cycle phase. 

Acquirer - An organization that acquires a capability, such 
as an information system. 

Adaptation - The tailoring of the life-cycle and documentation 

standards (within the specifications of the rules and guide- 
lines) for a specific program/project, information system, 
or component . 

Allocation - The process of apportioning requirements at one level 
in the decomposition tree to the subsystems or subcomponents 
at the next lower level in the decomposition. 

Assembly - A physical element of a hardware component consisting 
of one or more line replaceable units. A hardware component 
is composed of one or more physical assemblies. 

Assurance - Includes any and all activities, independent of 
organization conducting the activity, that demonstrate 
the conformance of a product to a prespecified criteria 
(such as to a design or to a standard). 

Assurance Specification - One of the four documents in the docu- 
mentation set for an information system or component; it en- 
compasses all the technical (i.e., non-planning) aspects of 
the assurance activities for an information system or compo- 
nent . 

Baselining - The official acceptance of a product or its 

placement under configuration management as defined in the 
management plan. 

Code Q - (NASA) Office of Safety, Reliability, Maintainability, 
and Quality Assurance 

Component - 1) One of the three parts makinq up an information 
system: software, hardware, or operational procedures. 

2) A portion of a higher-level component of the same type; 
e.g., a component of the software component (of an information 
system) . 

Critical Design Review - The phase transition review for the 
Detailed Design life-cycle phase. 
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Data Item Description - The table of contents and associated 
content description of a document or volume. 

Design Element - An identifiable part of a component's archi- 
tectural design. 

Developer - The provider organization responsible for development 
of an information system or of a hardware, software, or 
operational procedures component. 

Document - One of the four basic types of information for each 
information system or component: 1) Management Plan, 

2) Product Specification, 3) Assurance Specification, and 
4) Management Control and Status Reports Document. A 
document consists of one or more volumes. 

Documentation Set - The four basic documents for each information 
system or component thereof. 

Evolutionary Acquisition - The acquisition of an information system 
over a relatively long period of time in which two or 
more complete iterations of the life-cycle will be employed 
to revise and extend the system to such an extent as to 
require a major requirements analysis and therefore subse- 
quent life-cycle iterations. 

Increment - A pre-defined set of units integrated for integration 
testing by the development organization in response to incre- 
mental development plans. 

Incremental Development - The process of developing a product 
before delivery in a series of segments. These segments 
remain internal to the development organization. The process 
is used to avoid the big bang approach to software development 
and help minimize risk. The segments are defined based on 
the design and documented in the design section of the product 
specification. The process leads to a single delivery unless 
used in conjunction with "phased delivery." 

Independent Verification and Validation - Verification and 

validation performed by an independent organization. In 
general, this is intended to be independent of the develop- 
ment organization. For complete independence, the IV&V 
organization must report directly to or be funded directly 
by the acquirer. 

Information System - 1) Any system composed of hardware, soft- 
ware, and operational procedures components required to 
process, store, and/or transmit data. 2) An integrated 
combination of software, hardware, and operational pro- 
cedures components that provides a useful capability. An 
information system is generally software-intensive. 
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Inheritables - Existing software or hardware to be drawn upon in 
developing a new information system. The inheritables may 
be modified to meet the new system's requirements. 

Instantiate - 1. To represent an abstraction by a concrete 
instance (e.g., heroes instantiate ideals). 2. Within 
Ada, the process of creating an instance of a generic 
subprogram or package. 

Line Replaceable Unit - A hardware unit that is part of an assem- 
bly that is defined to be the lowest replaceable element of 
a hardware component . An assembly is composed of one or more 
LRUs. 

Management Control and Status Reports Document - One of the 

documents in the documentation set for an information system 
or component ; it represents a "logical" home for all report 
and request forms. 

Management Plan - One of the four documentation set documents; 
it encompasses all planning information for an information 
system or component, including management, engineering, and 
assurance planning. 

Partitioning - The process of determining the content for each 
delivery when using the phased delivery approach, or for 
determining the content of each segment when using incre- 
mental development. 

Phase (of a life-cycle) - A set of activities and associated 

products and reviews that make up one step of a multi-step 
process for developing systems and their component. An 
information system life-cycle has seven standard phases: 

1) Concept and Initiation; 2) Requirements; 3) Design; 

4) Implementation Coordination (or Implementation or 
Fabrication) ; 5) Integration and Test? 6) Acceptance Test; 
and 7) Sustaining Engineering and Operations. In some cases, 
phase 3 contains multiple levels of design, such as archi- 
tectural and detailed. 

Phase Transition Review - The review at the end of a phase trig- 
gering transition to the next phase. 

Phased Delivery - The process of developing and delivering a 

product in stages, each providing an increasing capability 
for an information system or component. The process may be 
employed to provide an early operational capability to users, 
for budgetary reasons, or because of risk, size, or complex- 
ity. Each delivery must undergo acceptance testing prior to 
release for operational use. The capabilities provided in 
each delivery are determined by prioritizing and partitioning 
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the requirements. This must be documented in the require- 
ments section of the product specification. 

Preliminary Design Review - The phase transition review for the 
Architectural Design life-cycle phase. 

Product Specification - One of the four documentation set 

documents for an information system or component? it encom- 
passes all the engineering and technical support information 
related to the development of an information system or 
component. 


Prototyping - A process used to explore alternatives and minimize 
risks. Prototyping can be used in any life-cycle phase. 

The product of the process is a report. By-products (such 
as software, hardware, and models) of the process can be 
preserved for subsequent use. 

Provider - An organization providing a capability to an acquirer; 
e,g : ' developer or an organization providing independent 
verification and validation. 

Quality Assurance - A subset of the total assurance activities 
generally focused on conformance to standards and plans. 

In general, these assurance activities are conducted bv 
the SRM&QA organization. y 

Quality Engineering - The process of incorporating reliability, 
maintainability, and other quality factors into system, 
hardware, software, and operational procedures products. 

Repository - A collection of standards, procedures, guides 

practices, rules, etc. that supplements information con- 
tained in the documentation set for an information system 
° r component. In general, the documentation set describes 
what is to be done and the repository provides the "how- 
instructions . A repository usually contains information 
that is applicable to multiple information systems and com- 
ponents . 

Requirements Allocation - The process of distributing requirements 
of an information system or component to subordinate in- 
formation systems (subsystems) or components. 

Requirements Partitioning - The process of distributing require- 
ments of an information system or component to different 
deliveries in support of phased delivery. 

Requirements Review - The phase transition review for the Require- 
ments life-cycle phase. 
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Review Item Discrepancy - A type of discrepancy report used when 
reviewing documentation. 

Risk — The combined effect of the likelihood of an unfavorable 
occurrence and the potential impact of that occurrence. 


Risk Management - The process of assessing potential risks and 
reducing those risks within dollar, schedule, and other 
constraints . 

Roll-out - A mechanism for recording sections of a document in 
physical ly separate volumes while maintaining traceability 
and links. When using roll-out, a volume is subordinate 
to a parent document or volume. 

Software Management and Assurance Program - Sponsored by NASA 
Code Q to foster more effective and productive software 
engineering methodologies. 

Subsystem - In the information system decomposition context, a 
subsystem is an information system that is subordinate to 
a higher level information system and is parent to soft- 
ware, hardware, and operational procedures components, or to 
other (lower level) information systems. 

Template - Within these Standards, a template is a DID frame- 
work used in the roll-out process for defining the specific 
format of a section rolled-out into a physically separate 
volume . 


Test Readiness Review — The phase transition review for the 
Integration and Testing life-cycle phase. 

Testing - The process of exercising or evaluating an information 
system or component by manual or automated means to demon 
strate that it satisfies specified requirements or to iden- 
tify differences between expected and actual results. 

Tool - A hardware device or computer program used to help develop, 
test, analyze, or maintain another device or computer program 
or its documentation. (IEEE Std 729-1983) 


Unit - An identifiable part of a detailed design. A level of 
decomposition for the purpose of physical design and im- 
plementation for a software or hardware component. 

Validation - 1) Assurance activities conducted to determine that 

the requirements for a product are correct; i.e. to build the 
riqht product. 2) (IEEE Std 729-1983) The process of evalu- 
ating software at the end of the software development process 
to ensure compliance with software requirements. 
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Verification - 1) Assurance activities conducted to determine that 
a product is being built correctly in accordance with design 
and requirements specifications; l.e. , to build the product 
right. 2) (IEEE Std 729-1983) "The process of determining 
whether or not the products of a given phase of develop- 

ment . . . fulfill the requirements established during the 
previous phase." 

Volume - A physically separate section of one of the four docu- 
ments in a documentation set. 


9 . 0 NOTES 
None. 

10.0 APPENDICES 
None. 
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